As some may have noticed, FORK is broken in a big way in scsh 0.6 when
used in conjunction with multithreading:
All threads continue to run in the forked process. This is usually
not what you want, especially when you call FORK via & or RUN where
the FORK is immediately followed by an EXEC-EPF in the child. This
makes it essentially impossible to call, say, CGI scripts from the
multithreaded SUnet webserver, because in the time window between the
FORK and the EXEC, you have duplicate threads talking to the various
active connections.
Therefore, scsh 0.6.2 will have functionality which allows you to run
the child process thunk passed to FORK in a new command level,
effectively pausing all other threads. As there may be situations
where you legitimately want to have threads continue in the forked
scsh, I don't want to simply replace the definition. I could offer a
new procedure FORK-THIS-THREAD-ONLY (or something), but a whole bunch
of other procedures currently call FORK where the programmer might
want control over this decision as well.
My current take is have FORK start a new command level for the thunk
by default, and add another optional argument which, when true, means
the old behavior of continuing threads. The same optional argument
would be added to the various RUN/XXX* procedures and other
dependents.
The remaining question is what FORK should do when called without
arguments, and how to toggle the creation of a new command level in
this case. For uniformity, I suggest that (fork #f) do the same as
(fork) (or vice versa).
Comments or suggestions, anyone?
PS: Of course, this interface is now ugly as sin and will have to
be rethunk for post-0.6 scshen.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
|