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

TJay tjay.dreaming at gmail.com
Sun Jul 30 13:04:46 EDT 2006


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.)

Christian 2006-07-30:
>Maybe you should describe what you want to do in more detail, I can't
>imagine why you want that functionality from the top of my head
>except that you might have run into problems with multiple threads
>continuing to run in the child or with non-written buffers being
>flushed twice.

I want to write a program that loads a bunch of plugins at startup.
Each of those plugins can handle one task (from the user's
perspective). The programs forks then calls the appropriate plugin's
procedure when the user selects a task.

<Task-chooser process>   (GUI)
           |
<Parent process>--<data server process>
        /        |         \
<Fork> <Fork> <Fork>  (GUI)

At startup, the parent process loads everything, plugins, etc. Then it
forks and opens a window for the user to choose what he wants to do
(<task-chooser process>). The task chooser process will tell the
parent process to fork and call the appropriate procedure when the
user chooses a task (<fork>). The data server process stores all data
and passes them along pipes to the processes that are interested.

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.


tj



More information about the Gambit-list mailing list