Re: kern/58916: timerfd(2) claims ready for write

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58916; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58916: timerfd(2) claims ready for write
Date: Thu, 19 Dec 2024 08:34:07 +0700

     Date:        Wed, 18 Dec 2024 14:55:00 +0000 (UTC)
     From:        campbell+netbsd%mumble.net@localhost
     Message-ID:  <20241218145500.8B58E1A923B%mollari.NetBSD.org@localhost>
 
   | For a timerfd(2), select(2) returns writable if asked and poll(2)
   | returns POLLOUT|POLLWRNORM if asked.  (Also POLLRDNORM if asked.)\
 
 Seems reasonable to me.
 
   | In contrast, in Linux, select(2) never returns writable
 
 I don't know what Linux does on writes, is it also:
 
   | Writing to a timerfd fails with EOPNOTSUPP,
 
 If so, then I'd suggest Linux's poll/select has a bug.
 
   | so it's not useful to claim writable.
 
 Someone fails to understand the purpose of poll/select.   It isn't
 to inform the process that a read/write will succeed, it is to inform
 the process that a read/write will not hang.   There are too many possible
 results for select (which just returns 1 bit) in particular to be able
 to differentiate between different possible results (poll() possibly
 could, but doesn't really) - so there is no attempt to do that.
 
   | This doesn't appear to be a POSIX interface,
 
 Timerfd isn't (devices in general aren't) but select() and poll() are.
 Further, they're generic, while the actual implementation depends upon
 the underlying device, the functions themselves do not.
 
 What POSIX says of select() is:
     to see whether some of their descriptors are ready for
     reading, are ready for writing, or...
 
 That is, there won't be an EAGAIN (or similar) because the underlying
 device is not ready yet, nor would the call hang if not in non-blocking
 mode.   Whether there might be an error, EOF, or other return (or how
 much data might be successfully transferred) isn't conveyed by these
 interfaces.
 
 kre
 
 ps: not that I really care what timerfd devices consider ready or not.