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.h... 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)).