pselect vs select vs poll - Unix

This is a discussion on pselect vs select vs poll - Unix ; Can anybody enlighten me why POSIX has no variant of poll() with additional 'const sigset_t *sigmas' argument, like pselect() ? select/pselect have limit on max fd number, so we are forced to use poll(). If I need to use sigmask ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: pselect vs select vs poll

  1. pselect vs select vs poll

    Can anybody enlighten me why POSIX has no variant of poll()
    with additional 'const sigset_t *sigmas' argument, like pselect() ?

    select/pselect have limit on max fd number, so we are forced to use
    poll(). If I need to use sigmask argument, *and* to use poll(), what
    do we do ?
    Is POSIX missing something here ?

    Yakov

  2. Re: pselect vs select vs poll

    "Yakov" wrote in message
    news:ac0b6c96-b640-47fa-a4c2-dbf6310e57ce@8g2000hse.googlegroups.com...
    > Can anybody enlighten me why POSIX has no variant of poll()
    > with additional 'const sigset_t *sigmas' argument, like pselect() ?
    >
    > select/pselect have limit on max fd number, so we are forced to use
    > poll(). If I need to use sigmask argument, *and* to use poll(), what
    > do we do ?


    Use "the self-pipe trick" and avoid the need.

    > Is POSIX missing something here ?


    Is pselect() widely implemented?

    Alex



  3. Re: pselect vs select vs poll

    On Mar 3, 1:54 am, Yakov wrote:
    > Can anybody enlighten me why POSIX has no variant of poll()
    > with additional 'const sigset_t *sigmas' argument, like pselect() ?
    >
    > select/pselect have limit on max fd number, so we are forced to use
    > poll(). If I need to use sigmask argument, *and* to use poll(), what
    > do we do ?
    > Is POSIX missing something here ?


    Linux has 'ppoll', but it's not part of the standard. The 'pselect'
    function is kind of a weird hack. More sensible solutions should
    eliminate the need. I would go so far as to say 90% of the stuff
    people do with signals is weird hackery that can be done better in
    other ways.

    Odds are, even if you're interrupted by a signal, you will still need
    to process and file descriptors that were/are ready. So there is no
    rational reason for the signal to interrupt the file descriptor
    discovery operation. (Why interrupt something that still needs to be
    done?) In general, it's bad practice to be waiting for two
    fundamentally different types of things.

    DS

+ Reply to Thread