ignoring a process' last words: SIGPIPE ...

[Michael Meeks]

Hi Havoc,

On Thu, 2008-03-27 at 15:00 -0400, Havoc Pennington wrote:
> On Thu, Mar 27, 2008 at 11:51 AM, Michael Meeks
> <michael.meeks at novell.com> wrote:
> >         The fix seems at some level sane - though - really we don't want to
> >  have 2 poll records when 1 is sufficient - and if we could re-factor the
> >  READ and WRITE polls into a single poll record [ as in ORBit2 ] then we
> >  wouldn't need 'b)' at all. Also, peripherally, we would avoid a vicious
> >  'poll' bug in some 2.4.x kernels.
>
> I don't understand this btw, the poll is:
> _dbus_poll (&poll_fd, 1, poll_timeout);
> 
> Is that not what you mean by poll record? It's always 1 fd we poll on, right?

	As far as I code-read, the main-loop / polling in the daemon is done
in:

	dbus-mainloop.c (_dbus_loop_iterate):
		n_ready = _dbus_poll (fds, n_fds, timeout);

	in this case - we frequently add the same fd twice to 'fds' with two
different 'watches' on the same fd; where having only one would simplify
& improve the code and avoid this[1] known kernel bug. [ Besides the
fact that both watches ultimately call the same function - making it
rather unclear why we have two ].

	As we see in [ refs from 0.6 FWIW ]:

	dbus-transport-unix.c (unix_connection_set):

	we add two watches, a 'read' and a 'write' watch. The write one (a lack
of luck would have it) appears before the 'read' one in the poll record
=> we process the WRITE hangup without reference to the fact that we
have data left to read - which is what my patch works around.

	Clearly if we used a single Watch (& hence poll record) for both read &
write the code would be cleaner, simpler & more efficient wrt. handling
this case ( and less invasive: down to ~1 new line instead of ~30).

	HTH,

		Michael.

[1] - http://www.gnome.org/~michael/activity-to-2001-11.html#2001-08-16
some years old but obsolete ?
-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot