On 7/31/06, Christian christian@pflanze.mine.nu wrote:
At 1:04 Uhr +0800 31.07.2006, TJay wrote:
I wasn't thinking about file descriptors in particular. I was wondering whether gambit itself has any internal state that's not friendly with fork(). (I have no idea what these states might include.)
I think I've already given my non-authoritative answer (just a guess): if you have multiple gambit threads running, then call fork, both processes will continue running all the threads, and if you print some stuff to buffered ports but do not flush nor close (through the POSIX call) them, you'll get output being printed twice. I don't know how I would handle the former problem (I think there's no place where Gambit is doing this already; the only place where Gambit calls fork is in implements ___device_stream_setup_from_process in os_io.c and there is no need to shut down other threads as exec is called immediately).
I see. I've not thought of how threads would be affected, and I'd hate to think of the kinds of strange, hidden bugs I'd get from unflushed buffered ports. I'll have to be super careful if I do any forking.
BTW using fork as opposed to starting subprocesses using open-process will probably not give you much of an advantage, if you load all code as compiled shared libraries, since almost all shareable memory will then be shared anyway, and you don't seem to want to fork chilren at a high frequency.
You're right. It might be easier to just call open-process. Thanks for the heads up.
tj