On 30.08.2006, at 18:02, Tom Jackson wrote:
But with Tcl exec, you never call fork, screw around and then call
exec*(), do
you? Is this an issue for C level tcl? Maybe the issue is that fork
and exec
are separate calls, and something unplanned could happen between
the two, and
pthread_atfork makes the two calls atomic. (And maybe sometimes
even this
isn't enough?)
The problem is a Tcl notifier thread which does not get replicated
in a forked process. Therefore, it is unsafe to use ANY Tcl call
after the fork(), otherwise you can get stuck forever.
It is relatively trivial to fix that, but this is not the only issue.
Far more complex is the problem with mutexes being held by the
caller in the time of fork(). There has been a very long discussion
on Tcl core list about that yielding:
Generally it is unsafe to do *anything* with the Tcl lib
after the fork and before the exec.
Obviously we can now use nsproxy to call exec. I'm not sure if it
works for
every use of exec inside a full AOLserver, but it would be pretty
close.
nsproxy is fine as replacement for direct exec. It should however be
fixed
in Ns_ProxyMain() because of:
/*
* Make sure possible child processes do not inherit this one.
* As, when the user evalutes the "exec" command, the child
* process(es) will otherwise inherit the descriptor and keep
* it open even if the proxy process is killed in the meantime.
* This will of course block the caller, possibly forever.
*/
Ns_CloseOnExec(proc.wfd);
Also, there might be problems with nsproxy being called during the
server-startup but I cannot comment on that, as we don't use it at
that time.
Cheers
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
