[email protected], le sam. 20 sept. 2025 09:53:44 +0200, a ecrit: > Sep 16, 2025, 23:35 by [email protected]: > >> @@ -588,13 +590,26 @@ io_select_common (struct trivfs_protid *cred, > >> pthread_mutex_unlock (&global_lock); > >> return 0; > >> } > >> - > >> - if (cred->po->openmodes & O_NONBLOCK) > >> + if (*type & SELECT_READ) > >> { > >> - pthread_mutex_unlock (&global_lock); > >> - return EWOULDBLOCK; > >> + err = start_input(0); > >> + if (err) > >> + { > >> + *type = 0; > >> + pthread_mutex_unlock (&global_lock); > >> + return err; > >> + } > >> + } > >> > > > > Yes, that looks sensible. > > > > Is there a potential problem with this when selecting/polling on multiple > fds? So far I have only tried with 1 to make it easier or does libc handle > this?
libc handles the multiplexing of io_select messages. > >> The condition in io_select_common explicitly checks for O_WRITE I am not > >> sure if this is needed again because if it is not set select will return > >> before. > >> > > > > It doesn't seem to be needed again indeed. > > > >> It does not work at all if the pthread_mutex_lock is inside the while > >> block. > >> > > > > Mmm, the mutex management indeed looks wrong: at the end of the while > > loop it is not released. But that's unrelated to your issue, so we'd > > want to commit that alone. Could you check that that modification alone > > doesn't bring issues elsewhere on the system? > > > > On the guix hurd streamio is only used for kmsg which until recently was not > read by the syslogd in the cross compiled image I have been using. > > For someone using select + O_NONBLOCK there currently always only 1 iteration > of the loop. > With the inetutils syslogd (what is currently being used) it opens the the > kernel log in blocking mode but then uses poll to wait until it is readable > (because of the same reason this currently also does not work) > > I tried with the mutex_lock before and in the while(1) block and have not > experienced anything weird yet. Ok, I have pushed the change, thanks! Samuel
