gnutls error handling

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

I've been using the built-in gnutls stuff exclusively for all the tls
connections for a while now, and it seems to work fine, except for
certain situations that I'm not able to reproduce reliably.

Sometimes, Emacs starts using 100% CPU.  When I strace, I see that it's
in a poll loop, so the strace always looks like this:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
select(15, [3 4 8 10 13], [], NULL, {0, 15591}) = 2 (in [8 10], left {0, 15589})
read(3, 0xec9b94, 4096)                 = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
select(15, [3 4 8 10 13], [], NULL, {0, 15532}) = 2 (in [8 10], left {0, 15530})
read(3, 0xec9b94, 4096)                 = -1 EAGAIN (Resource temporarily unavailable)

There's always a gnutls socket involved in the select call -- in this
instance it was fd 10.  lsof showed the socket to be in the CLOSE_WAIT
state.  So my suspicion is that the we're somehow now communicating back
to Emacs that a gnutls socket has closed.

I'm not familiar enough with Emacs internals to know how that's supposed
to be done, and I'm not familiar enough with the gnutls library to know
how it reports this, so...  er...  help?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen