develooper Front page | perl.perl5.porters | Postings from December 2017

Re: [perl #127794] Strange behavior when forking in BEGIN

Thread Previous | Thread Next
Chad Granum
December 19, 2017 02:10
Re: [perl #127794] Strange behavior when forking in BEGIN
Message ID:
I can live without a fix. I just want to make sure no fatal errors occur
that will block my current code.

Would also be nice to have some xs code that lets you tell and seek on the
current source files handle/descriptor, as well as xs code to close it,
re-open the file, seek to the right place, and use that instead of the
original. Such low level access would allow people (like me) who want to
fork in begin manage the source files internal handle directly.


On Dec 18, 2017 5:20 PM, "Zefram" <> wrote:

> Chad Granum wrote:
> >That said, I would greatly prefer some kind of fix, though I understand
> >that is probably not gonna happen.
> Indeed.  A proper fix would amount to the child process getting a clone
> of the open file description for the source file, as opposed to a clone
> of the file descriptor referring to the same open file description.  It's
> difficult to draw the line regarding which open file descriptions should
> be cloned: things opened by the program might want the same treatment
> as source, but many things want the default sharing behaviour.  But that
> doesn't matter, because there's no way to clone open file descriptions.
> Failing that, the next best thing would be to detect when a conflict
> occurs.  You'd want to detect at read time that something else has
> performed a read on the same open file description since the last read
> you know about.  But that's also impossible.  For regular files you
> could look at the file position, but that's subject to race condition,
> and it doesn't apply at all to pipes.
> So no fix is going to happen.
> -zefram

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About