in reply to Re^3: Allowing user to abort waitpid
in thread Allowing user to abort waitpid

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        

  • Comment on Re^4: Allowing user to abort waitpid (select)

Replies are listed 'Best First'.
Re^5: Allowing user to abort waitpid (select)
by Anonymous Monk on Mar 07, 2016 at 23:35 UTC
    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 :)
[reply]
[d/l]
[select]
Re^5: Allowing user to abort waitpid (select)
by BrowserUk (Patriarch) on Mar 08, 2016 at 06:50 UTC
    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.
[reply]

In Section Seekers of Perl Wisdom