[gambit-list] Can Gambit programs be safely fork()'ed?
Christian
christian at pflanze.mine.nu
Sun Jul 30 14:27:11 EDT 2006
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:
>1) 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.
More information about the Gambit-list
mailing list