How should wasi-libc handle `POLLPRI`?

[alexcrichton]

In #754 it was discovered that there are applications, such as vim, which set the exceptfds argument to the select and pselect functions. The man pages for these functions indicate that this argument corresponds to the POLLPRI argument to the poll function. Prior to #754 wasi-libc didn't define POLLPRI as a constant and also returned an ENOSYS error if exceptfds was set for either select or pselect. In #754 this behavior has now changed where POLLPRI is defined, select and pselect thread fds to poll with POLLPRI set, and poll has some handling now. Specifically in poll it effectively ignores POLLPRI unless everything is exclusively waiting on that event in which case ENOSYS is returned.

I'm opening this issue to have some further discussion of this and see if anyone else has thoughts on this as well. Specific questions I would have are:

• Is anyone opposed to exposing POLLPRI in wasi-libc? Personally I feel this is justified because we already can't statically rule out setting exceptfds arguments in select and pselect. We've also found additionally over time that it's easier to provide constants/functions than to not provide them at all and ask applications to work around the lack of posix/unix/etc functionality. (at least in some cases, not necessarily all). Nevertheless I wanted to pose the question here: does anyone feel strongly that POLLPRI should not be exported by wasi-libc?

• Regardless of whether POLLPRI is publicly exported or not, what should the behavior of exceptfds be with select and pselect? I still frame this in my head as POLLPRI since select and pselect are effectively just poll in a different veneer personally. In my opinion we should interpret POLLPRI as effectively an event that never happens right now in wasi-libc since it's not hooked up to anything. The man page for POLLPRI says it's for things like TCP out-of-band data and some ioctl/tty things I don't know about, but nevertheless WASI has no concept of either of these. Given that I'd personally say that we should consider this as an event that basically never fires.

• If others agree with me that we should interpret POLLPRI as an event that never fires (yet, there's an orthogonal open question of whether WASI should provide functionality to support this), then do others disagree with changing the behavior of poll? I'd say that poll should probably just ignore POLLPRI entirely and it turns into a glorified version of sleep if you happen to wait exclusively on things with POLLPRI. Otherwise if you wait on a mixture of POLLPRI and other things it's just as-if the POLLPRI thing never fired.

cc @paralin as the author of #754, and cc @sunfishcode as you might have thoughts on API-side of things here too.

[paralin]

For context, from the PR discussion: I found only two real world cases where exceptfds is used:

1. TCP out-of-band (OOB) data: TCP has a "urgent" flag: sender can mark a single byte as out-of-band. select() reports the socket as having an exceptional condition. This is rarely used (telnet).

2. Pseudoterminal packet mode: (via TIOCPKT):
   But exceptfds doesn't report general errors like broken pipe or connection reset, these would show up as errors via getsockopt(SO_ERROR). So the usage here is unclear.

The now-merged approach of ignoring it unbreaks vim and other ncurses programs.