[gambit-list] Can Gambit programs be safely fork()'ed?

TJay tjay.dreaming at gmail.com
Sun Jul 30 21:28:51 EDT 2006


On 7/31/06, Christian <christian at 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



More information about the Gambit-list mailing list