Re: gnutls error handling

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <address@hidden>
> Date: Sun, 17 Oct 2010 19:18:21 +0200
> 
> It happened again just now:
> 
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
> select(20, [3 4 6 7 8 10 11 12 13 14 18], [], NULL, {0, 232293}) = 1 (in 
> [18], left {0, 232288})
> read(3, 0xec9b94, 4096)                 = -1 EAGAIN (Resource temporarily 
> unavailable)
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
> select(20, [3 4 6 7 8 10 11 12 13 14 18], [], NULL, {0, 232200}) = 1 (in 
> [18], left {0, 232195})
> read(3, 0xec9b94, 4096)                 = -1 EAGAIN (Resource temporarily 
> unavailable)
> 
> And fd 18 is:
> 
> address@hidden ~/pgnus]$ lsof | grep 29932331
> emacs      2687       larsi   18u     IPv4           29932331      0t0        
> TCP quimbies.gnus.org:35134->ew-in-f132.1e100.net:https (CLOSE_WAIT)
> 
> So that's again a gnutls connection in CLOSE_WAIT.

Does Emacs try to read from this fd (18 in this case)?  Because AFAIU,
a read from such a socket should return zero bytes, which could be
used as a sign that we need to close the file descriptor.

Or maybe this logic should be (or is) in gnutls, and there's either a
bug there or maybe we use it incorrectly.