<div class="gmail_quote">On Fri, Mar 30, 2012 at 2:48 AM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Using a read(2)/write(2) syscall per character seems really<br>
suboptimal to me, and because by default compilation is rather verbose,<br>
this also affects compilation performance.  I have written stdio<br>
alternatives in the past to solve similar problems, and could probably<br>
help for this...<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I didn't look very far yet, but I don't see code in file.d to put<br>
those descriptors non-blocking even in the<br>
ecl_make_file_stream_from_fd() case, so is buffering more of an issue<br>
than blocking?</blockquote></div><div><br></div><div>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.</div>

<div><br></div><div>Juanjo</div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>