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).
The reasons I want to do things this way are:
- The library I'm using for opening windows does not support multiple
windows. (I only open a window after forking, the parent process does not have a window open.) 2) Plugins won't bring the user's data with them when they crash.
You probably just need this functionality:
- create bindings to the following POSIX functions: fork, pipe, close. - call pipe the necessary number of times, then fork, then close on those pipe ends you don't need in the children/parents, then turn the fd numbers into Gambit ports using the recipy given by Marc a few days ago. - forget about threads if you don't start any in the parents, and forget about open ports as long as you don't write data to buffered ports without calling force-output before calling fork, and as long as you don't need to close them in all processes so as to make the receiver get an EOF (pipes). Or just remember to call close-port on those which really need to be closed.
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.
Christian.