Any machine-level stray pointer in a pure Perl (no XS, no API calls) program is by definition a Perl bug.

In a compiled language, a debugger easily spots the instruction doing that and lets you view the stack to see what it was up to. I don't know how you'd do it in Perl. A general-purpose mechanism would be to "confess" the stack trace any time a machine-level exception or signal is encountered. I have no idea how to set things up to do that, but I think it ought to be built-in.

—John

I've never had any difficulty getting Perl to crash when using the emulated fork under Win32. Even trivial programs will crash or just plain "act strange". It is so easy to get it to fail that I haven't even bothered filing a bug report (just picking which of dozens to send in first would be a problem).

As for multiprocessing, I've mostly replaced fork with:

    if(  @ARGV  &&  $ARGV[0] eq "-child"  ) {
        shift( @ARGV );
        # child code here
        exit( 0 );
    }

    # Am parent
    # ...
    system(1,$^X,$0,"-child",@ARGV); # run child
    # ...
[download]

in cases when I needed it.
        - tye (but my friends call me "Tye")

Could you explain what is going on here a bit? I'm a novice Perl coder, and my first professional script needs to be modified to include a second fork... which, of course, kills me entirely on this blasted Win32 environment. I'm hesitant to use your workaround without understanding exactly what is going on, though.

I need to spawn two children, each of which are non-perl exe files, and one of which may be killed and respawned multiple times over the life of the parent.

--


Believe nothing, no matter where you read it, or who said it - even if I have said it - unless it agrees with your own reason and your own common sense.
(Buddha)

This may very well have been true back in 2001, I do remember having problems if I loaded DBI before fork()ing, but I AM running several multithreaded services (daemons for the Unixers) for two or three years already. Works fine. I do not keep creating and destroying threads though, in one service I only have two threads ("watcher" and "worker"), the number of threads in the other depends on the INI file, but again I create them upfront.

Jenda


We'd like to help you learn to help yourself Look around you, all you see are sympathetic eyes Stroll around the grounds until you feel at home    -- P. Simon in Mrs. Robinson