GDBus socket code ...

[Michael Meeks <michael meeks novell com>]

Hi there,

	After the mythically curious dbus socket code [ as Havoc says
~"re-writing it would be easier than understanding it" ] - I was full of
enthusiasm for the new gdbus.

	The new code, while more readable and promising, seems to have a few
drop-offs. The first I noticed was getting a raise (SIGABRT); when a
socket buffer is full, and sendmsg fails with EAGAIN (as seen in e-d-s).

	Sadly under strace the timings change and I no longer get the EAGAIN to
prove it (sad but true), but with this:

diff --git a/gio/gdbusprivate.c b/gio/gdbusprivate.c
index cd6eb91..c0b445d 100644
--- a/gio/gdbusprivate.c
+++ b/gio/gdbusprivate.c
@@ -997,6 +997,8 @@ write_message_in_idle_cb (gpointer user_data)
                           data,
                           &error))
         {
+         if (error && error->code == G_IO_ERROR_WOULD_BLOCK)
+               g_error ("crash and burn on EAGAIN\n");
           /* TODO: handle */
           _g_dbus_worker_emit_disconnected (worker, TRUE, error);
           g_error_free (error);

	I can get a nice console g_error of the same type before I get the
SIGTERM ;-) Since e-d-s shunts really quite a lot of data over the bus
this is rather a common case.

	In historic types in ORBit2 / linc - we had a custom GSource (which
IMHO is well worth stealing), for which we could strobe the poll
conditions easily [ though perhaps in glib that is easier anyway ].

	Thus - when we hit an EAGAIN on write, we would immediately switch our
poll to wait until there is space on the socket buffer (G_IO_OUT), and
get on with processing any other data / backlog and/or sleep.

	It -seems- as if the approach in gdbus (as of now) is to have an idle
handler running in the I/O thread [ the I/O thread model is a good one
IMHO ], that will rapidly turn into a busy loop - simply re-dispatching
the idle handler indefinitely [ assuming we don't fail on EAGAIN ;-]
until we can write the data.

	Is that the ultimately intention ? or is this just somewhat
under-finished ?

	I was also rather surprised to get this SIGTERM behaviour since all
calls to set_exit_on_close pass FALSE that I can see anywhere ;-)

	Thanks,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot