On 26-09-17 14:10, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> On Windows, exceptfds of select() is not only related to urgent ("out of band") data, it also notifies connect() failure:
> 
> exceptfds:
> 
>      If processing a connect call (nonblocking), connection attempt failed.
>      OOB data is available for reading (only if SO_OOBINLINE is disabled).
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx
Ok. So what is achieved with the wrapper method is to catch a connection 
attempt failure error on the writefds, by signaling a WRITE_EVENT on the 
writefd.

Application will then most likely try to write to the fd and an error 
will occur, telling us the connection attempt failed.

I will try to change the wrapper method so that it still contains this 
hack (because that is what it is IMO), but also allows other fds to be 
monitored for exceptional events.

> 
> I'm not sure that we can easily simplify the third parameter of select() as "urgent data". The exact semantics seems to not be portable at all.
The goal of the patch is not to simplify the third parameter of select, 
but simply to extend the selectors module with the ability to subscribe 
for the POLLPRI ('urgent data to read') event, so selectors module can 
be used with sysfs gpio kernel driver.

To support this in SelectSelector the third parameter of select needs to 
be used, causing other exceptional events like POLLERR and POLLHUP to 
trigger select as well. For PollLikeSelector, this has always been so, 
because one does not need to register for POLLERR and POLLHUP (and 
POLLNVAL).

The goal of the selectors module is to offer a platform-independent 
abstraction layer on top of I/O monitoring functions in select. Our goal 
is to extend this with the ability to handle exceptional conditions.

Because some people get confused using the word 'exceptional' when 
programming in Python, I was asked to use one of the accepted synonyms. 
Since POLLPRI is the only exceptional condition event we explicitly need 
to register for, this is the description we choose. IMHO, this 
description makes what we try to accomplish harder to understand, than 
it was confusing.

> 
> poll() describes better the event types. Extract of my local Linux poll() manual:
> 
> POLLPRI: "There is urgent data to read (e.g., out-of-band data on TCP socket; pseudoterminal master in packet mode has seen state change in slave)."

> 
> POLLERR: "Error condition (only returned in revents; ignored in events)."
> 
> POLLHUP: "Hang up (only returned in revents; ignored in events).  Note that when reading from a channel such as a pipe or a stream socket, this event merely indicates that  the  peer closed its end of the channel.  Subsequent reads from the channel will return 0 (end of file) only after all outstanding data in the channel has been consumed."
> 
> etc.

> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue30844>
> _______________________________________
>