in reply to Multi-OS Perl fork

Are you saying that fork() doesn't work as advertised on Win32? That would be news to me. Or does your Win32 code do something additional that fork() does not do? What? I'm confused; perhaps you could explain?

Replies are listed 'Best First'.
Re^2: Multi-OS Perl fork
by Corion (Patriarch) on Sep 06, 2005 at 13:46 UTC

    I haven't seen any "advertising" for fork() on Win32, but it doesn't work well enough. It seems to work for the people who implemented it, for their exact needs. It cannot work well with sockets and it has problems when running longer processes.

    I've never mustered the strength to track down these problems, but I'm quite sure that they stem from the fact that the fork() emulation is just that, an emulation, and that the parent and forked child are not separated completely. It was easy enough to circumvent this problem in my case, by writing Schedule::Cron::Nofork, but in many other cases, especially test programs, fork() Just Doesn't Work on Win32.

      I haven't seen any "advertising" for fork() on Win32

      By "as advertised", I didn't mean "as advertised specifically for Win32" but more like "as explained in standard documentation, such as the Camel book". I learned Perl from the 2nd ed. Camel while I was still using Windows 95 OSR2, with ActivePerl, and fork *seemed* to work for me, although I never used it extensively.

      It cannot work well with sockets and it has problems when running longer processes.

      Ah. I was not aware of these limitations. I knew that fork didn't work on DOS, but I was not aware that it had issues on Windows.

        Forking on Win32 is done via Perl threads. See perlfork for details.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.