Calling 'select' from emacs_gnutls_pull

[Eli Zaretskii <eliz@gnu.org>]

Ted,

I need your help in understanding the implementation of
emacs_gnutls_pull.  Specifically, why does it need to call 'select'
when 'sys_read' returns EWOULDBLOCK?  The file descriptor should
already be watched by the call to 'select' in
'wait_reading_process_output', so it seems like a call to 'sys_read'
is all that's needed here.  Am I missing something?

The reason I ask is that someone reported seeing these messages when
running Emacs on Windows under a debugger:

  warning: sys_read called when read is in progress

This comes from 'sys_read', and it means that the reader thread (used
by Emacs to read from a socket) is already blocked inside a call to
'recv' on behalf of this file descriptor, when 'sys_read' is called.

I think that the sequence of events which leads to this is as follows:

  . emacs_gnutls_pull calls sys_read, which returns EWOULDBLOCK,
    because there's no data ready to be read

  . emacs_gnutls_pull then calls select, which wakes up the reader
    thread and tells it to try reading from the socket

  . the reader thread blocks inside the call to recv (since no data is
    ready)

  . the call to select times out and returns EWOULDBLOCK, which causes
    emacs_gnutls_pull to break from the loop and return EAGAIN

  . after some time, emacs_gnutls_pull is called again, and calls
    sys_read while the reader thread is still blocked in recv, so we
    get the above message

Is this a plausible description of what might happen?  If so, would it
make sense to avoid calling 'select' in emacs_gnutls_pull, and instead
let 'wait_reading_process_output' call 'select', as it does for all
the other sockets open in Emacs?  Or am I missing something?

TIA