946Re: Forking from a dispatched class
- Oct 22, 2001Mike/Paul/Sean,
Just to confirm, I just had the same problem on Linux (2.2
My client app hangs until the child process gets killed. When I
implemented the KillSocketSOAPHTTPDaemon module everything works
If you look in the Perl Cookbook, Ch 17.9, it tells you the same as we
I had hoped there would be a neater way to access the socket guts of
the HTTP::Daemon that SOAP::Lite used for the handler. Rather than
having to re-write a whole replacement ::Daemon myself. Perhaps you
could add a method ...->shutdown(1|2|3).
Thanks for saving me the the time to do it anyway!
--- In soaplite@y..., Michael Percy <mpercy@p...> wrote:
> > -----Original Message-----
> > From: Meisner, Sean [mailto:Sean.Meisner@V...]
> > Sent: Tuesday, July 31, 2001 2:13 PM
> > Ummm, can't recall the exact train of thought that led me to 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.
> That sounds about right... I was really confused and about to embark
> > I *think* that Solaris will be the only OS that would benefit
> > this patch, but I'm not sure on that. I seem to remember being
> > that other systems handle forking with open sockets in a
> > cleaner fashion.
> I don't know if this is the case or not, but this issue definitely
> at least a relnote! Checking on the linux manpage for fork(2), it
> -- 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> ...
> 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> ...
> Solaris> open file descriptors
> Solaris> ...
> Obviously Solaris does this explicitly, while on Linux is not quite
> documented but seems likely. Since file locks != file descriptors,
> don't think resource utilizations would include FD's, I am assuming
> trying it that Linux follows the same behavior as Solaris on this
> Can anyone developing on Linux verify this behavior?
- << Previous post in topic Next post in topic >>