[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