Re: [PATCH] SIGPIPE redux -- please review
Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org:
I think the patch introduces a descriptor leak.
Not according to my tests. I repeatedly hit the code in the patch and
didn't see any increase in fds in /proc. Would this be O/S dependent?
The lstream needs to be closed, but we either must avoid flushing
its buffers them or ignore the SIGPIPE when we flush them. The
latter will do for now, but we should add a "no flush" flag to
lstreams so that the lstream close method can avoid trouble when we
know the remote endpoint of a socket has gone away.
Unless there's an O/S which does leak descriptors, I think the patch I
posted is good enough. The condition certainly seems rare enough that
even if some system did leak descriptors it wouldn't be that bad, and
it's certainly better than a coredump.
Alternately an Lstream_discard_buffers function might work as well
and have other uses.
Of the two suggestions, a "no flush" flag sounds like the better idea.
I'm pretty sure that I fixed the Gnus SIGPIPE crashes last year,
but
it probably got undone with process.c got ripped apart during the
Windows frenzy.
I don't know.
That would explain the deja vu feeling related to these crashes.
I did get Deja Vu looking over the code where the crash was occurring.
I'm reasonably certain this was fixed at some point. Without my
patch, it is definitely broken on the system I'm testing on.