Re: hang in gconfd

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> Hi Owen,
> 
> On 11 Dec 2001, Owen Taylor wrote:
> > 100% CPU still hangs with linc as of this morning -- to quote
> > linc-connection.c:linc_connection_writev():
> 
>         Ok - so there are two problems; firstly the bug in the application
> that is not responding - which is it ? we have to block somewhere or we
> will consume 100% memory writing to a non-responsive process.

Unfortunately, I couldn't figure out what process it was - it still
hung when I killed just about all the processes that might be
connecting to gconfd, and then went away when I killed a process that
shouldn't have been connected to gconfd at all. I'll do some more
investigation if it happens again.

Well, you never _have_ to block the process... it's perfectly
legitimate to start dropping oneway calls on the floor once your
buffers are exhausted.

Or you could ues client side buffers that you allow to grow without
bound. Or you could could combine the two behaviors and possibly
blocking the client in some fashion.

There probably will be some need for API to allow callers to choose
what behavior they want at some point if 'oneway' continues to be used
extensively for this purpose. (async normal methods should allow for
more flexibility on the part of the client.)

(Having one way calls recurse the main loop strikes me as
being pretty unexpected behavior... and strikes me as liable
to cause really deep stacks in some cases)

>         Secondly - we should make it more efficient to block here; I
> assume handing G_IO_OUT constantly and in a more intelligent fashion in
> linc_connection_connected, combined with a linc_main_iteration (TRUE) will
> have this effect.
p
I don't know the details, but yes, if you are polling waiting for
G_IO_OUT, and the argument to linc_main_iteration() corresponds to
that of g_main_iteration(), this should prervent the 100% CPU busy
wait.

Regards,
                                        Owen