This (waitpid returning) may be the case with OP's legacy environment... Current perl appears to set up the signal handlers with SA_RESTART

PP(pp_waitpid)
{
    ...
    if (PL_signals & PERL_SIGNALS_UNSAFE_FLAG)
        result = wait4pid(pid, &argflags, optype);
    else {
        while ((result = wait4pid(pid, &argflags, optype)) == -1 && er
+rno == EINTR) {
      PERL_ASYNC_CHECK();
        }
    }
    ...
[download]

There is some mention in perlipc: On systems that supported it, older versions of Perl used the SA_RESTART flag when installing %SIG handlers. This meant that restartable system calls would continue rather than returning when a signal arrived. In order to deliver deferred signals promptly, Perl 5.8.0 and later do not use SA_RESTART. Consequently, restartable system calls can fail (with $! set to "EINTR") in places where they previously would have succeeded. The default ":perlio" layer retries "read", "write" and "close" as described above; interrupted "wait" and "waitpid" calls will always be retried.

Well, I stand corrected, then.

Right, I stand corrected, too. The SA_RESTART is used only when unsafe signals are requested (environment PERL_SIGNALS=unsafe). Thank you.

nixers are a funny bunch.

Ask about how to multiplex a few hundred tcp clients transferring gobs of data, and they'll almost universally suggest using a select loop, or other polled event mechanism; which in modern high-speed comms environments requires polling with millisecond or smaller resolution to be responsive to even tens of clients. And that can consume 60% to 70% of a cpu just polling.

But ask about getting conditional input from the guy sitting at the keyboard, which requires polling no more than once every 1/10th of a second, which will consume so little cpu that it won't even show; and they call it hackish.

select only involves polling when done incorrectly.

And that can consume 60% to 70% of a cpu just polling.

Yeah, when I use select, it doesn't burn CPU when waiting.

- tye        

Well, select (and poll) do have inherent limitations. For each call to select the kernel must check all specified descriptors to see if they are ready. Performance of that depends on the number of descriptors. Also, in a busy application select can be called very often. I think it's fair to call it 'polling'.

With epoll and other similar mechanisms, it's only necessary to register all 'interesting' descriptors once, and then, when IO happens on some descriptor, the kernel checks if the application is interested in it. Therefore, performance is determined by the number of IO events.

If we have a ton of descriptors, but, at any given time, IO actually happens only on some small percent of them, epoll will vastly outperform select, because, yes, it does less 'polling'.

Yeah, when I use select, it doesn't burn CPU when waiting.

But do you have 10k concurrent connections :)

select only involves polling when done incorrectly.

Okay. So the provision of the timeout parameter is just an otherwise redundant trap for the unwary.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

Not a good example, select and poll are indeed slow and not recommended for "a few hundren tcp clients"; use epoll/kqueue/signal-driven IO (well, maybe not signal-driven IO).

use epoll/kqueue/signal-driven IO

There are several problems with that advice:

• They're not available from Perl.
• They'e not POSIX.

  I agree, POSIX is increasingly irrelevant as it isn't a useful representation of *nix any more. (Or for the last two decades for that matter.)

• epoll doesn't work with timers, signals, semaphores, processes, network devices. Not even disk files.

  Yes, there are the calls signalfd(), eventfd(), and timerfd_create(); but they don't help much.

• epoll maybe O(1) for event notifications, but it remains O(n) for modifications to the interest set.

  Fast changing, dynamic descriptor sets require many and frequent calls into the kernel for epoll_ctl(), which gets expensive.

• kqueue addresses most of that, but retains one major flaw in modern systems: Per process interest sets.

  Basically, it hasn't caught up with the advent of the multi-core architectures that are now ubiquitous; which means you can't easily split your loads across those multiple cores by using multiple thread running separate event loops.

  Yes, you can use multiple processes; but that creates the problem of coordination and data sharing between those processes.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.