about summary refs log tree commit diff
path: root/contrib/palaver/pounce-palaver.1
diff options
context:
space:
mode:
authorJune McEnroe <june@causal.agency>2020-11-16 15:04:39 -0500
committerJune McEnroe <june@causal.agency>2020-11-16 15:04:39 -0500
commit09af6dcd618701bc5994b4a146e6df34e1cf9015 (patch)
treecbc26cac234aaf730cdd169736b02f8ee58c75e3 /contrib/palaver/pounce-palaver.1
parentSwap localAccept parameter order (diff)
downloadpounce-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 'contrib/palaver/pounce-palaver.1')
0 files changed, 0 insertions, 0 deletions