Let me try to explain more clearly, I was trying to do to many different things at once.
Sep 3, 2025, 18:54 by samuel.thiba...@gnu.org: > > > It's very hard to follow because the references you use can be > ambiguous.. > >> I have never questioned the EWOULDBLOCK on the first read, >> > > What do you mean by "questioned"? Which "first read" do you mean? Is > your program calling read() before calling select()? > If one just starts reading without select and O_NONBLOCK the initial read (any read when input_buffer is empty) will always EWOULDBLOCK. As current select always claims readability this also happens with select and is the behaviour I demonstrated in the initial message. >> this was also happening before he previous change already and looks expected >> (although I admit it is a bit weird)? >> > > If there is nothing to read, it's indeed normal to get EWOULDBLOCK on a > O_NONBLOCK file descriptor. > >> After a start_input with empty input_buffer and nowait dev_read returns >> EWOULDBLOCK as no messages are (immediately) available. >> > > Does the device_read_request_inband() call inside start_input() return > D_WOULD_BLOCK? Does device_read_reply_inband get called with errorcode > == D_WOULD_BLOCK? > No. I don't think so. >From what I have tried with kmsg device_read_request_inband() always >succeeds.device_read_reply_inband gets called with errorcode== D_WOULD_BLOCK >only when kmsg currently has no more messages. >> After that it is readable >> > > After what? From what I read above dev_read was returning EWOULDBLOCK. > Currently you have to trigger the first device_read_request manually with a read and ignore the error. Then things work until the input_buffer is empty again. >> until the "end" >> > By "end", do you mean the current end of file? > Yes, device_read_reply_inband returning 0 data + D_WOULD_BLOCK when currently no more messages are available. >> where it now also EWOULDBLOCKs as opposed to D_WOULD_BLOCK >> > > What do you mean by "as opposed?" Normally userland should only ever see > EWOULDBLOCK, and we would convert D_WOULD_BLOCK into EWOULDBLOCK. Where > do you get D_WOULD_BLOCK vs EWOULDBLOCK exactly? > This is fixed by the previous patch now. What I was trying to explain that if device_read_reply_inband was returning D_WOULD_BLOCK inappropriately it would have been returned by read earlier than the current end of file. >> (unless one exactly manages to empty the input_buffer, i.e. by reading in >> chunks of 1). >> > > Do you mean that if one call io_read() with more than 1, we might get > stuck in a situation where we don't manage to empty the pending > characters? > Currently there is a problem when the input_buffer is empty. This definitely happens at the start or end, but I think could also happen in the middle somewhere by accident. At least I ran into problems trying to read 1 char at a time manually. >> If there was a D_WOULD_BLOCK >> > > Where do you mean there could be a D_WOULD_BLOCK? > >> it would have failed with D_WOULD_BLOCK much earlier than the "end". >> > > AIUI we wouldn't want to get any D_WOULD_BLOCK before the actual end of > file? > Yes, i think this is exactly what is happening. I think there is no problem there. >> I tried to add a start_input/start_output to request data if none is >> available >> > > Where did you add it exactly? > >> but it did not work and select (with NULL timeout) was still waiting. >> > > Waiting, while there is still data to read, you mean? > >> Should this be before or after the pthread_hurd_cond_timedwait_np? >> > > By: > >> > 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, >> > > I didn't mean to add calling start_input() in io_select_common, > but in device_read_reply_inband(), in the case where errorcode == > D_WOULD_BLOCK. Because we are consuming the opportunity of reading data > from the device, so we'd have to trigger another one by calling > start_input() to make another device_read RPC call. > I see, I misunderstood your message. Wouldn't this still be incomplete in the case when no read has happened yet? What about the case when the input buffer becomes empty somewhere in the middle of the available messages? > Samuel >
