in reply to HPUX corruption of file handle after fork

Abe:

Remove the line:

close $fh or die "Can't close $fh";

[download]
The children messing with (closing, in this case) the file handle is likely the cause of your problem. You might still have a problem with the children sharing a single copy of $Sql, but i've never used fork in perl before, so I couldn't say.

...roboticus

Update: I forgot to tell why the line ought to be cut.

Replies are listed 'Best First'.
Re^2: HPUX corruption of file handle after fork
by Abe (Acolyte) on Dec 10, 2007 at 16:49 UTC
    Roboticus -

    Thanks very much for your swift answer.

    I had tried with and without the line, and no difference. I've just tried again to be quite sure.

    My understanding of fork at the OS level is that file descriptors in the parent are dup()'d to the child. The child has to close the fd or at least not move it by reading from it.

    It's almost as if when I issue close() perl is repositioning the file pointer before close()ing at the OS level.

    If I get rid of the close(), I still have the problem, so maybe exit() does it implicitly

    INTERESTING:

    If I change exit(0) to: 

    exec /bin/false

    [download]
    (so that I get _exit below decks instead of perl's wrapped exit(),) IT WORKS!!

    So I think perl is fiddling with file descriptors in the child in its exit function.

    If I then restore the explicit close(), the problem returns!!

    So perl close() is altering the position in the file via the child's file descriptor.

    I wonder whether that happens on Solaris, Linux, Aix - I've only HPUX to look at.

    Regards, Abe

[reply]
[d/l]

In Section Seekers of Perl Wisdom