in reply to Windows filehandles and fork

I'll be honest, I'm not entirely certain what is going on here, but here are two versions that at least seem to work. Perhap's some kind monk can tell me (and the OP) why these seem to work properly.

if ($pid=fork() ) {
    select(undef,undef,undef,.1);
        open (STDOUT, ">test.txt");
    print "parent\n";
    
} else {
    print "child\n";
}

[download]

... and...

if ($pid=fork() ) {
    #select(undef,undef,undef,.1);
    print "parent\n";
} else {
    open (STDOUT, ">test.txt");
    system("echo child");
}

[download]

update: commented out the select line in second example.

Just Another Perl Alchemist

Replies are listed 'Best First'.
Re: Re: Windows filehandles and fork
by egarland (Acolyte) on Apr 09, 2004 at 02:45 UTC
    The first one works as expected for me. Parent goes into the file, child goes to STDOUT. The second one does the same as mine. I've tested it on Activeperl 5.8.2 on WinXP Home and 5.8.3 on Win2000 Pro. It prints both child and parent into test.txt even though, from what I understand, the child shouldn't be able to manipluate the parent's STDOUT.
[reply]
Re: Re: Windows filehandles and fork
by egarland (Acolyte) on Apr 09, 2004 at 06:36 UTC
    Commenting out the select line makes it likely that the parent will run it's print before the child does the open(STDOUT) which is causing the problem. You are then in a nasty state because then whenever the child get's arround to opening STDOUT, the parent's print statements will be spontaneously redirected. This is bad behavior.

    It looks to me like something is broken in the fork emulation in ActivePerl.

[reply]

      I'd most likely agree with you, but to be honest I don't know to much about fork and how it's supposed to work. I am still in the process of studying the appropriate chapter in the Camel. But I do recall it mentioning that forks in perl were implemented with threads of some sort ( ithreads I think ) but was bent to more resemble a Unix Fork.

      I do hope I made it clear in my first post that I didn't really know what was going on. I am however, curious why my first example seems to run as expected, or is this also a situation of the open happening after the other process has already printed it's message.

      I'm also not entirely clear as to what select is doing. I can't seem to find any mention of that particular form in perlfunc. And neither of the two mentions in perlipc seem to say what they're doing.

      Update: Ack, Just realized I should probably look in the camel, and managed to dig up what select is doing, apparently it's just putting a minor delay in one of the processes, I assume the purpose in the initial verion was to make certain that one process' print happened after the other's open, so it would seem that both my examples seemed to have the desired effect only due to (in one case) the random chance of one of the print's happening before the open. And in the other case because the open itself was delayed, making certain that the other process got it's print out beforehand. bleh...

      Just Another Perl Alchemist
[reply]
        Yes, The select's were for sub-second pauses. Sorry. I've probably been programming in perl too long, I don't even notice I'm using tricks like that anymore. I should have put sleep()'s in there instead to make it clear.

        So you see my issue, changing the timing changes where the output goes which makes it unpredictable and dangerous. Perl isn't usually unpredictable or dangerous. Something is wrong here.

        The guys who do POE seem to have gotten something like this working, although their code is all in modules so first I'd have to figure out how to get POE to do what I want, then I'd have to trace the code to see what it's doing all without knowing if it actually does work right.

[reply]

In Section Seekers of Perl Wisdom