Re: hang in gconfd

[Michael Meeks <michael ximian com>]

Hi Havoc,

On 10 Dec 2001, Havoc Pennington wrote:
> That helps with ping(), but I also have notify() etc. I believe in
> ORBit1 this was the wacky function involving a fork() and so on,
> wasn't it? It's no longer doing that right? ;-)

	Yes - or at least, it was 'going to' use fork; I don't think it
ever did, I think non_existant is quite safe to use in both stable and
head and will help reduce the problem.

> Ah, very useful!

	Quite :-) - part of how the new control lifecyle is supposed to
work.

> I discussed this with Jody on IRC last night, makes sense, we had the
> same theory on the blocking and same proposed solution.

	Ok - the problem is then; deciding quite how much data you want to
queue. The application can ( in theory ) sit in a tight loop indefinately
while you queue up megabytes of notifications to send to it - which is
somewhat sub-optimal. So ... either way, we can at least try and make it
'more' non-blocking in some sense.

> I do agree the "oneway method, exit()" sequence breaking is bad as
> well. atexit() doesn't un-bad it

	Quite - I don't like atexit; I like shutdown methods :-)

> I can investigate, at least at some point. This is a really-must-fix
> sort of thing. Which files do I look at?

	Ok - so what you want to do is see linc/src/linc-connection.c; my
preferred solution would be: if writev (or write) fails with an EAGAIN
then we need to serialize ( and flatten ) what we have left to write, and
append it to a queue of things to write, and flag that this connection is
blocking.

	Subsequent writes to that connection will be queued, until we get
a G_IO_OUT on the connection; at which point we resume trying to write the
queue until we block again - etc.

	It shouldn't actualy be that hard, and it shouldn't involve any
API breakage I think :-)

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot