Thanks for the insight. I can't quickly make a value judgement on the choice of non-blocking mode - existing NUT codebase uses both O_NDELAY (seemingly in code dealing with Unix or TCP sockets, including the case here with upssched daemon/CLI interactions) and O_NONBLOCK (seemingly for serial-port connections, and for TCP sockets in nutclient.cpp `Socket::connect()` and upsclient.c `upscli_tryconnect()`).
Otherwise, what you describe as poll() returning no error and read() returning a 0 - that does match the situation I see. My memory is vague on what @dtsecon tried to achieve in PR 1274 by adding this line to `if (ret==0) continue` (possibly worked around some delays? are those possible after the select() says the FD is ready?) - and so if that use-case gets broken again by bailing out quickly here. I guess my proposal in https://github.com/networkupstools/nut/pull/1965 - which is to only immediately abort if explicit errors are seen, and abort after trying to read() hard enough - is sort of best of two worlds, or least-worst :) WDYT? Jim On Wed, Jun 14, 2023 at 3:15 PM Sam Varshavchik <[email protected]> wrote: > Jim Klimov via Nut-upsuser writes: > > > So... determining that FD is to be reaped proved hard. Internet lore > suggests > > fcntl() and poll() on the FD, but it just seems valid to them. The errno > is > > also usually not raised (once I saw a "111: Connection refused" though). > > So the best dumb idea so far is to bail out if we spent the whole loop > (128 > > attempts) and only got zero-sized read replies and no errors. > > It's been my experience, that the path of least resistance is: > > 1) The sockets are sets to be non-blocking > 2) poll() > 3) If poll() says the socket is readable, and read() returns <= 0, then > the > socket is dead. You get no error, and read() returns 0, if the socket had > an > orderly shutdown. > > _______________________________________________ > Nut-upsdev mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
