diff options
author | June McEnroe <june@causal.agency> | 2020-11-16 15:04:39 -0500 |
---|---|---|
committer | June McEnroe <june@causal.agency> | 2020-11-16 15:04:39 -0500 |
commit | 09af6dcd618701bc5994b4a146e6df34e1cf9015 (patch) | |
tree | cbc26cac234aaf730cdd169736b02f8ee58c75e3 /configure | |
parent | Swap localAccept parameter order (diff) | |
download | pounce-09af6dcd618701bc5994b4a146e6df34e1cf9015.tar.gz pounce-09af6dcd618701bc5994b4a146e6df34e1cf9015.zip |
Set client sockets non-blocking
Except for during writes. This prevents pounce getting blocked on a client sending only a partial TLS record, for example. Writes still need to block because pounce doesn't have a way to resume them. (And it would do so by having a buffer, but sockets already have a send buffer, so what would be the point of that?) I don't think it should be a problem since outside of stateSync, writes only happen when poll returns POLLOUT. I feel like ideally SO_SNDLOWAT would be set to guarantee a full IRC message can always be written on POLLOUT, but since it's actually TLS records being sent, it's not obvious what the size would be. I'm also making an assumption here that tls_read returning TLS_WANT_POLLOUT is unlikely to happen, since I don't actually set pollfd.events based on that. I'm not sure how wanting to resume a tls_read after a POLLOUT could be cleanly handled. I'm just going to hope that if it does happen, the regular poll loop will eventually sort it out...
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions