Editing POLLHUP polling

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
'''This page is a work in progress'''
Recently I've been trying to listen on multiple sockets at once for events like reading or writing. This has worked fine, but as I've tried to listen for a socket close event I've found the documentation poor and often contradictory. This page is my attempt to figure this topic out.
Recently I've been trying to listen on multiple sockets at once for events like reading or writing. This has worked fine, but as I've tried to listen for a socket close event I've found the documentation poor and often contradictory. This page is my attempt to figure this topic out.


Line 57: Line 59:
  #include <string.h>
  #include <string.h>
   
   
  int do_test(short events, const char *data) {
  short do_test(short events, const char *data) {
   /* create a socket pair, one end for parent, one end for child */
   /* create a socket pair, one end for parent, one end for child */
   int sockets[2];
   int sockets[2];
Line 77: Line 79:
   if(rc < 1) { printf("poll err %i\n", errno); return 1; }
   if(rc < 1) { printf("poll err %i\n", errno); return 1; }
   printf("do_test events %x data %p: %0x\n", events, data, fd.revents);
   printf("do_test events %x data %p: %0x\n", events, data, fd.revents);
  return 0;
  }
  }
    
    
Line 98: Line 99:


== Linux ==
== Linux ==
On Linux 5.19 it seems that polling a closed socket will return:
On Linux 5.19 it seems that polling a closed socket will always return the following events:


* POLLIN if checking
* POLLIN if checking
Line 105: Line 106:


This is regardless of whether there is data in the socket to read.
This is regardless of whether there is data in the socket to read.
This behaviour is not POSIX compatible as POLLHUP and POLLOUT are supposedly mutually exclusive. The source code notes this is to prevent stuck sockets.


[https://man7.org/linux/man-pages/man2/poll.2.html The Linux poll man page] specifies the following:
[https://man7.org/linux/man-pages/man2/poll.2.html The Linux poll man page] specifies the following:
Line 114: Line 113:
* POLLHUP indicates a pipe or socket has the peer end closed
* POLLHUP indicates a pipe or socket has the peer end closed
* The events bitmask can be empty
* The events bitmask can be empty
The history for Linux's behaviour is as follows:


* 1997: Linux 2.1.23pre1 added the poll system call, with no AF_UNIX socket support
== FreeBSD ==
* 1998: Linux 2.1.106pre added AF_UNIX socket support. POLLHUP is returned on socket close
FreeBSD 13.1 POLLIN|POLLHUP always set:
* 2000: Linux 2.3.41pre2 returns POLLIN on empty socket close
 
POLLIN: 1 POLLOUT: 4 POLLHUP: 10
 
do_test events 0 data 0x0: 10
 
do_test events 1 data 0x0: 11
 
do_test events 4 data 0x0: 10
 
do_test events 5 data 0x0: 11
 
do_test events 3f data 0x0: 11


== FreeBSD ==
do_test events 0 data 0x20072e: 10
On FreeBSD 13.1 it seems that polling a closed socket will return:
 
do_test events 1 data 0x20072e: 11
 
do_test events 4 data 0x20072e: 10
 
do_test events 5 data 0x20072e: 11
 
do_test events 3f data 0x20072e: 11


* POLLIN if checking
== NetBSD ==
* POLLHUP always, even when checking for no events
NetBSD 9.3


This is regardless of whether there is data in the socket to read.
localhost$ ./a.out


The [https://www.freebsd.org/cgi/man.cgi?sektion=2&query=poll FreeBSD poll man page] has less information than the POSIX standard.
POLLIN: 1 POLLOUT: 4 POLLHUP: 10


It's not documented but the events bitmask can be empty.
poll err 0


The history of FreeBSD's behaviour is as follows:
do_test events 1 data 0x0: 1


* 1997: [https://svnweb.freebsd.org/base?view=revision&revision=29351 FreeBSD r29351 implements poll] based on NetBSD's code. POLLHUP is not returned by sockets
do_test events 4 data 0x0: 4
* 2009: [https://svnweb.freebsd.org/base?view=revision&revision=195423 FreeBSD r195423 adds POLLHUP for sockets]
* 2009: [https://svnweb.freebsd.org/base?view=revision&revision=196460 FreeBSD r196460 improves poll conformance for sockets] by returning POLLHUP more often instead of POLLIN
* 2009: [https://svnweb.freebsd.org/base?view=revision&revision=196556 FreeBSD r196556 fixes POLLHUP on half-closed sockets] by only returning POLLHUP on fully closed sockets and returning POLLIN on empty buffers


== OpenBSD ==
do_test events 5 data 0x0: 5
On OpenBSD 7.1 it seems that polling a closed socket will return:


* POLLIN if checking
do_test events 3f data 0x0: 5
* POLLHUP always, even when checking for no events


This is regardless of whether there is data in the socket to read.
poll err 0


This behavior is identical to FreeBSD's behaviour.
do_test events 1 data 0x400dec: 1


The [https://man.openbsd.org/poll.2 OpenBSD poll man page] specifically notes that POLLERR can indicate a socket disconnection.
do_test events 4 data 0x400dec: 4


It's not documented but the events bitmask can be empty.
do_test events 5 data 0x400dec: 5


The history of OpenBSD's behaviour is as follows:
do_test events 3f data 0x400dec: 5


* 1996: [https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/sys_generic.c.diff?r1=1.4&r2=1.5 OpenBSD implements poll]. POLLHUP is not returned by sockets
???
* 2013: [https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/sys_socket.c.diff?r1=1.16&r2=1.17 OpenBSD implements POLLHUP on sockets]


== NetBSD ==
== BSDs ==
On NetBSD 9.3 it seems that polling a closed socket will return:
- openbsd


* POLLIN if checking
- illumos
* POLLOUT if checking


This is regardless of whether there is data in the socket to read.
- macos??


The [https://man.netbsd.org/poll.2 NetBSD poll man page] specifically notes that "Sockets produce POLLIN rather than POLLHUP when the remote end is closed".
== Windows ==
cygwin:


Leaving the events bitmask empty causes poll to timeout.
$ ./a.exe


The history of NetBSD's behaviour is as follows:
POLLIN: 1 POLLOUT: 4 POLLHUP: 10


* 1996: [http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_generic.c.diff?r1=1.27&r2=1.28&only_with_tag=MAIN NetBSD implements poll] and [http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_socket.c.diff?r1=1.14&r2=1.15&only_with_tag=MAIN NetBSD implements poll support for sockets] at the same time. No POLLHUP is implemented for sockets, existing select behaviour is kept
poll err 0


== MSYS2 on Windows ==
do_test events 1 data 0x0: 1
On MSYS2 in 2022 polling a closed socket will return:


* POLLIN if checking
do_test events 4 data 0x0: 4
* POLLOUT if checking


This is regardless of whether there is data in the socket to read.
do_test events 5 data 0x0: 5


MSYS2 does not have any specific man pages.
do_test events 3f data 0x0: 5


Leaving the events bitmask empty causes poll to timeout. This makes sense because the implementation is emulating select using poll. The history for MSYS2's behaviour is as follows:
poll err 0


* 2000: [https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=afb7e7196a6dc16c145a455d6cf0761cbaeb7a48 Cygwin implements the poll system call]. POLLHUP is set as a single event if a file descriptor is closed
do_test events 1 data 0x10040307c: 1
* 2002: [https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=7382e593a01ee81cea5df91a77a9868281de8c04 Cygwin peeks sockets]. POLLHUP is now set if a socket is closed
* 2005: [https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=6ba3f6bb2d088c7b5ffc84a6ed74ad3d525fde37 Cygwin switches to POLLIN when peeking]. POLLHUP is now only set if a file descriptor is closed
*2011: [https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=0077cd1016c8414f6175f8e94f97be9ea4506bea Cygwin checks socket shutdown status]. POLLHUP is now generated if a socket is shutdown
*2018: [https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=b79018ee3a36140a82e2dfa2d7a71fc0bf15d892 Cygwin only detects Winsock socket shutdowns]. Now POLLHUP no longer applies to AF_UNIX sockets


== poll emulation ==
do_test events 4 data 0x10040307c: 4
Many applications that run on systems without poll will attempt to emulate it using the select function.


A naive emulation works like this:
do_test events 5 data 0x10040307c: 5


* Map pollfds with POLLIN to select's readfds
do_test events 3f data 0x10040307c: 5
* Map pollfds with POLLOUT to select's writefds
* Map pollfds with POLLPRI to select's errorfds
* Call select
* Map the readfds to the pollfds POLLIN return events
* Map the writefds to the pollfds POLLIN return events
* Map the errorfds to the pollfds POLLPRI return events


This has two problems:


* POLLHUP and POLLERR are not returned
wsapoll
* pollfds with no events are not mapped at all


Usually select will trigger a read event if the socket closes, so POLLHUP can be emulated using a peek. But this doesn't work if a pollfd has no events at all to check.
== Emulation ==
wine?


== Conclusions ==
cygwin
Linux is the only system that documents the behaviour of polling only for POLLHUP. Next to that are FreeBSD and OpenBSD where the behaviour works and probably won't be changed as applications in the wild depend on it. Outside those systems I have no clue if this is a viable solution to this problem.


In general I have a sour feeling towards poll. It mixes up the task select does of waiting for system calls to not block with reporting a vague status of a file descriptors that you would learn about anyway by using system calls. POLLHUP feels like and reads like an afterthought.
minix


In the future I'm definitely going to be using epoll or kqueue for my work. These tools have proper documentation and give concrete guarantees about how my program is going to work.
my dosbox code :(
[[Category:Research]]
Please note that all contributions to JookWiki are considered to be released under the Creative Commons Zero (Public Domain) (see JookWiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)