704RE: [soaplite] Forking from a dispatched class
- Jul 31, 2001
> -----Original Message-----...
> From: Meisner, Sean [mailto:Sean.Meisner@...]
> Sent: Tuesday, July 31, 2001 2:13 PM
> Ummm, can't recall the exact train of thought that led me to thatThat sounds about right... I was really confused and about to embark on that
> solution, but I think I burned a good 2 or 3 work days of reading
> man pages on fork and socket calls and looking at the SOAP::Lite
> and HTTP::Daemon code to figure out what was going on.
> I *think* that Solaris will be the only OS that would benefit fromI don't know if this is the case or not, but this issue definitely warrants
> this patch, but I'm not sure on that. I seem to remember being told
> that other systems handle forking with open sockets in a
> cleaner fashion.
at least a relnote! Checking on the linux manpage for fork(2), it states:
-- from Linux.com: http://www.linux.com/develop/man/2/fork/
Linux> fork creates a child process that differs from the parent
Linux> process only in its PID and PPID, and in the fact that
Linux> resource utilizations are set to 0. File locks and pending
Linux> signals are not inherited.
Linux> The fork call conforms to SVr4, SVID, POSIX, X/OPEN, BSD 4.3.
While on the manpage for Solaris, it says:
-- for Solaris:
Solaris> The fork() and fork1() functions create a new process. The
Solaris> new process (child process) is an exact copy of the calling
Solaris> process (parent process). The child process inherits the
Solaris> following attributes from the parent process:
Solaris> open file descriptors
Obviously Solaris does this explicitly, while on Linux is not quite
documented but seems likely. Since file locks != file descriptors, and I
don't think resource utilizations would include FD's, I am assuming without
trying it that Linux follows the same behavior as Solaris on this one.
Can anyone developing on Linux verify this behavior?
- << Previous post in topic Next post in topic >>