anyone have an opinion on whether poll() on a connection-oriented AF_UNIX socket should be able to give you POLLHUP, even if you didn't specify POLLIN?

context is illumos #18080

linux says yes you can get POLLHUP, and you even get woken up for it

BSDs say no, you never get POLLHUP on a UDS (even with POLLIN!), you have to read or write and look for EOF or SIGPIPE

actually sorry that isn't true for more modern BSDs, they will give you POLLHUP but only if you ask for POLLIN

but pfd.events = 0 will never wake you up

(or any pfd.events value that doesn't include POLLIN)

maybe I should just ask the list lol

:) I guess ppl are sleeping still in US

or rather, already;)

haha it's probably also the kind of thing that is best considered for a bit before replying. better fit for the list than irc ;)

arekinath: I agree with your analysis of #18080. It's a bug that we *usually* wake up the waiter but don't *always* wake it up. Sending extra events is less likely to induce application misbehavior than withholding them.

yeah I don't think the current situation we're in could _not_ be a bug, it's inconsistent and basically racey haha

just a matter of whether we stop trying to deal in HUPs for UDS altogether like BSD does, or add in the missing wakeups to get to the Linux semantics

I get paranoid about unintended consequences in these dusty little corners though

I guess if user code is currently working on us though, it means it does already cope with getting POLLHUP on UDS, sometimes

since we do already give it to them, just not consistently

so maybe getting rid of it altogether is more likely to cause problems than getting it consistently?

certainly seems true with LX and other users of devpoll/epoll

arekinath: yeah, that's my take -- the current behavior may work well enough that disabling the events to match BSD would lead to hangs of thought-to-be-working applications.

yeah, i'd lean towards the linux behavior.. (not having heavily used UDS sockets, the linux behavior is closer to what i'd expect)

our man page says " The event flags POLLHUP, POLLERR, and POLLNVAL

are always set in revents if the conditions they indicate are true;

this occurs even though these flags were not present in events."

so I think that seals it.

[illumos-gate] 18000 tty group id should use a named constant from sys/param.h -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 17994 Duplicate link entries accumulate in devlink database without bound -- Andy Fiddaman <illumos⊙fn>

Hey Ya'll sorry for the basic question but does anyone know of an illumos disro that will work on arm? I'd ideally like to run something like omni on a rasp pi but it  seems like builds for this don't exist? What's the arm progress for illumos is this something I could do myself?

For arm builds, see downloads.omnios.org/media/braich

[illumos-gate] 18077 RPC fixes after 16390 -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 18076 NFSv4.0 Client Receives NFS4ERR_DELEG_REVOKED -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 18034 libscf: deadlock in `scf_value_set_from_string` with some invalid values -- Robert Mustacchi <rm⊙fo>