[Ecls-list] Locking strategy (best so far) (unbuffered streams)

[Juan Jose Garcia-Ripoll]

On Fri, Mar 30, 2012 at 2:48 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> When pulling changes, I noticed a conflict with my local changes in
> file.d, the part using unbuffered descriptors, and it reminded me that
> my local change was to keep buffering with threads.  If I understand
> threaded and non-threaded builds would now use unbuffered descriptors.
>

This is not a design choice. It is a debugging change that slipped through
the commits. Will fix it later when I get back home.


> Using a read(2)/write(2) syscall per character seems really
> suboptimal to me, and because by default compilation is rather verbose,
> this also affects compilation performance.  I have written stdio
> alternatives in the past to solve similar problems, and could probably
> help for this...
>

I do not think there is a need for rewriting stdio. The C files are left
for those who need raw access, for instance because they implement their
own buffering, or send huge streams of data in the form of arrays. In the
case of the standard input/output, they are also used because they seem to
be the only form of input/output that does not cause problems when multiple
threads try to create a prompt.


> Also, I didn't look very far yet, but I don't see code in file.d to put
> those descriptors non-blocking even in the
> ecl_make_file_stream_from_fd() case, so is buffering more of an issue
> than blocking?


Wrong choice of words. By blocking I did not mean that they do not wait for
input or wait till output is done, but the fact that FILE runs through a
mutex means concurrent operations from different threads block each other,
no matter what they are. This lead to serious instabilities in the code for
sharing the prompt, but I must admit this was engineered by another person
and have not looked at it in a long time.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120330/8f41c7b8/attachment.html>