Re: In the BEGINing there were no forks?

Actually, this gets weirder, consider

BEGIN{if(fork){die}}
[download]

and

BEGIN{if(!fork){die}}
[download]

On Activestate 5.8.4, the first produces

Died at fork.pl line 1.
BEGIN failed--compilation aborted at j2.pl line 1.

whilst the second

panic: restartop

Now why should that be?

Comment on Re: In the BEGINing there were no forks? Select or Download Code

Replies are listed 'Best First'.
Re^2: In the BEGINing there were no forks? by RazorbladeBidet (Friar) on Feb 14, 2005 at 20:38 UTC
The only thing I can think of would be that fork is returning undef because it was unsuccessful I've never actually seen that message (panic: restartop) before, though.	[reply]
Re^2: In the BEGINing there were no forks? by Animator (Hermit) on Feb 14, 2005 at 20:59 UTC
The first error has nothing to do with fork. It happends always and on every os (or atleast on the ones I tested)... I guess it comes because the BEGIN-block is run at compile-time, and the compiling of the code failed. (you called die...) `perl -wle "BEGIN { die; }"` produces exactly the same error. I guess (I'm not sure of this at all!) that the second error occures because the parent died before the child was run... (! fork() means not undef, and not 0, if the parents executes fork() then it returns the pid of the child which is not 0). ~~This would then mean that the proces is dead, but that there are still threads alive, which should give problems (or not?)... (I could be wrong on this one, as I said, I'm guessing)~~ ~~The fork emulation on Windows creates a new thread inside the proces, fork on unix/linux/... creates a new proces, which is slightly different I guess.~~ Update, as RazorbladeBidet I got it backward.. What was I thinking? :)	[reply] [d/l]
Re^3: In the BEGINing there were no forks? by RazorbladeBidet (Friar) on Feb 14, 2005 at 21:02 UTC
I think you have it backwards (or maybe I do - it's getting late for me :) ) `if (!fork) { die; }` [download] Should die only when fork is not true, that is 0 or undef. Thus, it's either the child (which really doesn't make sense because a dying child is no big deal) or it's undef, which means something bad happened. The first one, as you said, is your normal error. I didn't think that one was under question.	[reply] [d/l]