Remove the line:

close $fh or die "Can't close $fh";
[download]

...roboticus

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

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

I think the file position keeps flipping back, because I see the message to STDERR report early blocks repeatedly.

Are you sure they're being reported repeatedly, or just somewhat out of order (which would be the expected behaviour due to runtime differences of the forked processes)?.

I just tried it (with a simple test file containing dummy SQL_REPORT_ID sections) on HP-UX 11.00, 11.11 and 11.23 with Perl 5.8.4 and 5.8.8, and I'm unable to reproduce the problem you describe. I.e., the proper $Sql content, $ReportId etc. are reported once each, as expected.

Are you doing anything else in the forked processes than what you've shown in the snippet above, or should that in fact already exhibit the problem?

Thanks very much almut - yes I'm absolutely sure.

However - we are on perl 5.8.0 (corporate stuff.)

I really think this'll be a perl 5.8.0 issue - do you?

We're probably not free to go to 5.8.8 right now, but I believe I understand the problem now and what to watch out for.

See my earlier reply to self with what I found with exec /bin/false to force use of run-time lib _exit.

Thanks so much for your help.

Abe

I just played around with this some more (I somehow had the feeling that you know what you're doing... ;)  and I can now reproduce the problem. Initially, I had rather short content in my dummy SQL_REPORT_ID sections. So, to simulate longer read times, I added a sleep 1 like this

      ...

      while (<$fh>) {
         last if (/END SQL_REPORT_ID/) ;

         $Sql .= "$_";
      }
      sleep 1;

      ...
[download]

and now I'm getting this (when doing print STDERR "Generated $ReportId: $Sql"; in the child):

Generated 1: foo 1
Generated 2: foo 2
Generated 3: foo 3
Generated 4: foo 4
Generated 2: foo 2
Generated 3: foo 3
Generated 4: foo 4
(2..4 repeated ad infinitum...)
[download]

This is on HP-UX (no difference between 11.00, 11.11 and 11.23) — on Linux, however, everything is fine. I'll try other platforms later and report back...

For the record, my test file contains:

SQL_REPORT_ID 1
foo 1
END SQL_REPORT_ID

SQL_REPORT_ID 2
foo 2
END SQL_REPORT_ID

SQL_REPORT_ID 3
foo 3
END SQL_REPORT_ID

SQL_REPORT_ID 4
foo 4
END SQL_REPORT_ID
[download]

Update: in case anyone is interested, here are the results for a couple of other platforms I could find:

No problem on

• Linux (various versions, going back to kernel 2.2)
• AIX 4.3, 5.1, 5.3
• Mac OSX 10.4.10

but same problem as on HP-UX, on

• Solaris 2.6 (SunOS 5.6), Solaris 8, 9 and 10
• IRIX 6.5

(don't know what to make of it, yet...)