Your message dated Mon, 23 Sep 2013 21:06:34 +0200
with message-id <[email protected]>
and subject line Re: Bug#602019: manpages-dev: poll manpage describes non-posix
behaviour as posix-conformant
has caused the Debian Bug report #602019,
regarding manpages-dev: poll manpage describes non-posix behaviour as
posix-conformant
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
602019: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602019
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: manpages-dev
Version: 3.25-1
Severity: minor
The poll manpage says:
The timeout argument specifies an upper limit on the time for which poll()
will block, in milliseconds.
While posix (all versions i bothered to check) require very distinct semantics:
If none of the defined events have occurred on any selected file
descriptor, poll() shall wait at least timeout milliseconds for an
event to occur on any of the selected file descriptors.
So in POSIX the timeout is a lower bound in the case where no other events.
There are two big practical differences in behaviour between both alternatives:
- "maximum times" cannot really be guaranteed on multitasking systems
- event libraries that rely on the posix behaviour require at least twice
as many iterations, as the kernel will often consistently return "too early"
requiring another wait.
I know that epoll_wait (which also specifies a maximum time) on at least
2.6.32 implements this "may return too early", and if poll uses the same
mechanism it is not posix conformant, and this behaviour difference to
posix should be mentioned due to it's relatively big practical difference
to a posix implementation.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages manpages-dev depends on:
hi manpages 3.25-1 Manual pages about using a GNU/Lin
manpages-dev recommends no packages.
Versions of packages manpages-dev suggests:
ii man-db [man-browser] 2.5.7-4 on-line manual pager
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 3.42-1
On Sun, Oct 31, 2010 at 09:15:34PM +0100, Marc Lehmann wrote:
> Package: manpages-dev
> Version: 3.25-1
> Severity: minor
>
>
> The poll manpage says:
>
> The timeout argument specifies an upper limit on the time for which poll()
> will block, in milliseconds.
>
> While posix (all versions i bothered to check) require very distinct
> semantics:
>
> If none of the defined events have occurred on any selected file
> descriptor, poll() shall wait at least timeout milliseconds for an
> event to occur on any of the selected file descriptors.
>
> So in POSIX the timeout is a lower bound in the case where no other events.
Fixed since 3.42:
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=19257d8fe647ab05aa3668429048e83c43062f2c
---
commit 19257d8fe647ab05aa3668429048e83c43062f2c
Refs: man-pages-3.40-48-g19257d8
Author: Michael Kerrisk <[email protected]>
AuthorDate: Wed May 2 07:57:08 2012 +1200
Commit: Michael Kerrisk <[email protected]>
CommitDate: Mon May 7 15:30:14 2012 +1200
poll.2: Clarify that 'timeout' is a *minimum* interval
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <[email protected]>
---
--
Simon Paillard
--- End Message ---
