<div class="gmail_quote">On Mon, Mar 15, 2010 at 9:42 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Is *debug-io* what the debugger uses?  If so, can it use a different<br>
FILE *, even if it's connected to the same underlaying FD as another<br>
stream (if it so happens to be connected to the same "tty")? </blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">As for<br>
user applications trying to read from a common stream using multiple<br>
threads, it would seem to be an application design mistake to me...<br clear="all"></blockquote></div><br>Tell that to people filing bug reports :-)<br><br>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.<br>
<br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>