Hello,
Sep 1, 2025, 19:10 by [email protected]: > Hello, > > yelninei--- via Bug reports for the GNU Hurd, le lun. 01 sept. 2025 14:36:32 > +0200, a ecrit: > >> Trying to use streamio with O_NONBLOCK and select results in select claiming >> that the fd is readable but when trying to read returning EWOULDBLOCK. >> >> >> Removing the O_NONBLOCK check in io_select_common makes select behave (I >> tried with timeout of NULL, 0 and 10s) >> > > This O_NONBLOCK check indeed looks wrong: select() is not supposed to be > affected by O_NONBLOCK, and just block. Does your system work fine with > that change? We should probably land it, patch welcome! > I have only tested the read part. When data is available (after the first failing read) or with a or no timeout it works as I would expect. Removing the check changes it from claiming that (with NONBLOCK) it is readable immediately to never. I guess this is more accurate as reading indeed WOULDBLOCK but not really ideal unless the empty input_buffer/output_buffer case is handled. >> however the input_buffer stays empty forever so it is never woken up. Any >> ideas? >> > Does device_read_reply_inband get called with errorcode == D_WOULD_BLOCK? > I wonder if in that case we'd be supposed to call start_input again, to > make another device_read request. If that second request gets > D_WOULD_BLOCK immediately, there is something wrong in the kernel driver > itself that doesn't manage to let us block. > I have never questioned the EWOULDBLOCK on the first read, this was also happening before he previous change already and looks expected (although I admit it is a bit weird)? After a start_input with empty input_buffer and nowait dev_read returns EWOULDBLOCK as no messages are (immediately) available. After that it is readable until the "end" where it now also EWOULDBLOCKs as opposed to D_WOULD_BLOCK (unless one exactly manages to empty the input_buffer, i.e. by reading in chunks of 1).If there was a D_WOULD_BLOCK it would have failed with D_WOULD_BLOCK much earlier than the "end". I tried to add a start_input/start_output to request data if none is available but it did not work and select (with NULL timeout) was still waiting. Should this be before or after the pthread_hurd_cond_timedwait_np? Maybe I also have a misunderstanding of how these work? Also do we need to acquire the mutex_lock on every iteration of the loop? > Samuel >
