or you don't understand what happens in my code when it runs on Linux. (Did you actually run it on a Linux system?)
No. I don't use Linux. And you're right. I did misinterpret what I saw in your post.
My main purpose was to point out:
See the PERL_ASYNC_CHECK() in run.c and Perl_despatch_signals(pTHX) in mg.c
See also perldoc/perlipc:
Long-running opcodes
As the Perl interpreter only looks at the signal flags when it is about to execute a new opcode, a signal that arrives during a long-running opcode (e.g. a regular expression operation on a very large string) will not be seen until the current opcode completes.
The rest was an attempt to understand (from your posted output) how linux was apparently able to interrupt flock when it appears to be implemented as a single opcode; and thus (according to my understanding of safe signals) should not be interruptible.
I don't understand why that works for you, unless you have PERL_SIGNALS=unsafe?
The (wrong) explanation I came up with seemed to fit; but then it is well passed the end of my (logical) day here and I'm somewhat punchy.
In reply to Re^6: Strawberry Perl and alarm() on Windows
by BrowserUk
in thread Strawberry Perl and alarm() on Windows
by bloonix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |