Loading ...
Sorry, an error occurred while loading the content.

704RE: [soaplite] Forking from a dispatched class

Expand Messages
  • Michael Percy
    Jul 31, 2001
    • 0 Attachment
      > -----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 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 on that

      > I *think* that Solaris will be the only OS that would benefit from
      > 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.

      I don't know if this is the case or not, but this issue definitely warrants
      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> ...
      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, 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?

    • Show all 12 messages in this topic