[gambit-list] Threads blocking and IO

Christian Jaeger christian at pflanze.mine.nu
Thu Jan 31 14:16:47 EST 2008


François Magnan wrote:
> Hi,
>
> Thank you all for your answers. The process I start with open-process  
> is a java application that uses it's standard input and standard  
> output for interacting with java classes through reflection. It is  
> some kind of bridge between the Gambit world and the Java world. The  
> bug appears on both Windows (MIngW) and MacOSX (Leopard).

For me that smells like the unix O_NONBLOCK problem (namely that 
toggling the nonblocking behaviour of an fd effects all processes 
sharing it; it could be that java turns off the nonblocking flag on a 
file descriptor it inherited from before the open-process, while gambit 
is still also using it; then when the Gambit runtime gets notification 
from the OS that IO is ready, java/whatever other process may be ready 
quicker than Gambit calling read or write on it, and when it's Gambit's 
turn to read/write, the system call blocks since there's no IO ready 
anymore (*)).

I'm not sure why that should happen on Windows though, do they actually 
have that same/equivalent problem as well?

If you were on Linux, I'd suggest you to run strace -fF around your 
program, then you'd easily see on which operation Gambit hangs, and with 
lsof you could see if the filehandles involved are in use by the other 
programs as well; I don't know what the equivalent tools on OSX and 
Windows are.

Christian.

(*) see my mail about a similar situation at 
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2006-January/000607.html 
for more details. Also note the way D.J. Bernstein solves it, by using a 
timer (a bit painful I'd say, since that assumes nobody else in the 
program will be making use of the timer, so either this would have to be 
optional (good idea) or SIGALRM handling would have to be virtualized 
(probably not worthwhile)).



More information about the Gambit-list mailing list