[Ecls-list] Unbuffered FD stream for stdin/out/err with threads

[Juan Jose Garcia-Ripoll]

On Mon, Mar 15, 2010 at 9:42 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> Is *debug-io* what the debugger uses?  If so, can it use a different
> FILE *, even if it's connected to the same underlaying FD as another
> stream (if it so happens to be connected to the same "tty")?


Maybe that is one option but now it occurs to me that concurrent access to
stdin is stupid anyway because there is no way to tell which thread will
receive the input. We obviously need something more clever.


> As for
> user applications trying to read from a common stream using multiple
> threads, it would seem to be an application design mistake to me...
>

Tell that to people filing bug reports :-)

Now, to be fair this time the wrong design is not really in the application,
but in the implementation. The application is free to read from stdin if it
wants, and it can not always control when errors are signaled. We obviously
need a way to grab the user input for the debugger and let other threads
idle waiting for input. I just can not think right now how to implement that
using just FILE or file descriptors -- my feeling is that when we use file
descriptors the debugger thread uses read() on the same file (stdin, tty) as
the other thread, the older thread gets interrupted with a TTY and the newer
one gains control. But that is just a guess. We need something more robust
where threads are allowed to preempt the standard input.

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/20100315/ab8b25e2/attachment.html>