pselect() modifying timeout

From: Michael Kerrisk (mtk-lkml_at_gmx.net)
Date: 08/05/05

  • Next message: Ingo Molnar: "[patch] preempt-trace.patch"
    Date:	Fri, 5 Aug 2005 12:42:24 +0200 (MEST)
    To: David Woodhouse <dwmw2@infradead.org>
    
    

    Hello David,

    By the way, looking at the comments to the last version of
    the pselect()/ppoll()patch, I see that the treatment of
    the timeout argument is made dependent on the personality.

    http://marc.theaimsgroup.com/?l=linux-kernel&m=111883591220436&w=2

    I'm not sure that this is a good idea; my reasons as follows:

    1. POSIX made the behaviour of pselect() explicit -- the
       timeout must not be modified. The idea was to avoid the
       vagueness of the select() specification; it had to be vague
       because of existing implementations. By contrast, there were
       no pre-existing implementations when pselect() was specified.
       (By the way, although one or two posts in the earlier thread
       implied that pselect() has long/widely been present on
       some systems, this is almost certainly not true. The only
       systems where I believe it is currently implemented are two that
       were recently Unix 03 certified: Solaris 10 and AIX (5.3?). I
       know from doing quite a bit of checking that it is not present
       as a kernel implementation on most (all?) other systems (even
       though it was already described by POSIX.1g and Richard
       Stevens 7 years ago))

       I haven't tested Solaris 10 and AIX, but I think one can be
       reasonably sure that they would conform to the letter of
       POSIX law. Lacking any strong reason to the contrary,
       Linux should (IMO) too (why gratuitously introduce
       differences across implementations?).

    2. The existing (non-atomic) glibc pselect() implementation
       does not change the timeout argument.

    Please consider making Linux pselect() conform to POSIX on this
    point.

    Cheers,

    Michael

    -- 
    5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
    +++ GMX - die erste Adresse für Mail, Message, More +++
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Ingo Molnar: "[patch] preempt-trace.patch"

    Relevant Pages

    • Re: [PATCH][4/4] poll()/select() timeout behavior
      ... It incorporates the poll overflow ... The timeout parameter controls how long ... Implementations may place limitations on the maximum timeout interval ... limitations on the granularity of timeout intervals. ...
      (Linux-Kernel)
    • EAP Session
      ... in that the timeout is set to 1 second with no retries. ... EAP request/Identity has an ID set to 1 and every second another request is ... // which works around these misbehaving implementations. ... control over so changing the timeouts and retries is not an option. ...
      (microsoft.public.windowsce.platbuilder)
    • Re: how long will select function be timeout when the last argument is set to NULL??
      ... >> Implementations may place limitations on the maximum timeout ... >> timeout interval of at least 31 days. ... Object hasn't list of pointers to waiting tasks, ...
      (comp.unix.programmer)
    • Re: [take24 0/6] kevent: Generic event handling mechanism.
      ... Newer syscalls (ppoll, pselect) take struct timespec, which is a reasonable, modern form of the timeout argument... ...
      (Linux-Kernel)
    • Re: how long will select function be timeout when the last argument is set to NULL??
      ... > AK> If the timeout parameter is a null pointer, ... > Implementations may place limitations on the maximum timeout ... This describes the behavior of a non-null timeout pointer, that is, ... specifies that earlier on in the standard, ...
      (comp.unix.programmer)