[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnutls error handling
From: |
Eli Zaretskii |
Subject: |
Re: gnutls error handling |
Date: |
Sun, 17 Oct 2010 20:43:39 +0200 |
> 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.