Re: hang in gconfd

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael@ximian.com> writes:

> Hi Havoc,
> 
> On 10 Dec 2001, Havoc Pennington wrote:
> > So, Owen discovered today that right now EAGAIN results in some
> > infinite-loop action - so this issue results in 100% CPU with ORBit2,
> > instead of blocking as in ORBit1.
> 
>         I fixed that bug a few days back - essentialy not checking the
> connection status having done a linc mainloop iteration. Should work with
> a HEAD linc. Otherwise - yes, it blocks on write - but we knew that anyway
> :-)

100% CPU still hangs with linc as of this morning -- to quote 
linc-connection.c:linc_connection_writev():

		while (size_left > 0) {
			int n;

			n = writev (fd, vptr, MIN (vecs_left, WRITEV_IOVEC_LIMIT));

			if (n < 0) {
				if (errno == EINTR)
					continue;

				else if (errno == EAGAIN &&
					 (cnx->options & LINC_CONNECTION_NONBLOCKING))

					linc_main_iteration (FALSE);
                        [...]
                        }
                   [...]
			if (cnx->status != LINC_CONNECTED)
				return -1;
                }

So, as long as it can't write (EAGAIN) it runs one iteration of linc_main_iteration(),
not and tries again. Eating up a great deal of my CPU unless something changes
cnx->status. But I don't see any particular reason the state would change when
trying to write to an unresponsive client.

Regards,
                                                     Owen