in reply to Re^3: Is this absurd, or have I not RTFM?
in thread Is this absurd, or have I not RTFM?
Between changes made in 5.16, safe signals, perlIO and buffering, an occasional duplication of some DESTROY printed messages isn't something I'd worry about .... unless it happens with perl-5.16.3 :)
This is not mere duplication of a printed message. As mentioned, when you enable the Devel::Peek statement you can see it's different references being provided in each call. Also this whole problem originated from a much more elaborate test-case where the result was that an XS module called free() twice on the same pointer in the same process. To my knowledge, this can't be explained with filehandles and buffers.
Also, there is always the possibility that while first Ctrl+C is being cached, and first server is being destroyed, another server is forked ...
Yeah... but strange that that new server get's the same PID as one of the old processes then.
I'd try only creating variables inside sub process_request as Net::Server::PreFork documents :)
I can't find that documented... anyway, that would of course be wise if the variable was a per-request variable. But this whole problem originated from needing to initialize a server global peace of data for all workers to be able to read.
And PS: ... The title hinted at the possibility that there was some documented caveat wrt. global destruction phase in certain Perl versions which I hadn't found. ... btw...this seems to happen only during global destruction
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: Is this absurd, or have I not RTFM?
by Anonymous Monk on May 19, 2014 at 08:27 UTC | |
by petermogensen (Sexton) on May 19, 2014 at 08:42 UTC | |
by Anonymous Monk on May 19, 2014 at 09:30 UTC | |
by petermogensen (Sexton) on May 19, 2014 at 10:03 UTC | |
by salva (Canon) on May 19, 2014 at 10:18 UTC | |
by Anonymous Monk on May 19, 2014 at 10:07 UTC | |
| |
by Anonymous Monk on May 19, 2014 at 10:15 UTC | |
|