[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

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.


More information about the Gambit-list mailing list