Re: GDBus socket code ...

[David Zeuthen <zeuthen gmail com>]

Hi,

On Wed, Aug 11, 2010 at 9:19 AM, Michael Meeks <michael meeks novell com> wrote:
> Hi David,
>
> On Wed, 2010-08-11 at 08:48 -0400, David Zeuthen wrote:
>> (Wouldn't it have been better to file this in bugzilla?)
>
>        As you like; wrt. a multi-pronged discussion of several related issues
> and deepen at least my understanding, so I thought here might be good
> but ...

Fair enough.

>> >        Is that the ultimately intention ? or is this just somewhat
>> > under-finished ?
>>
>> Right now, the intent is to block the IO thread until all data
>> has been written.
>
>        Ok; so - is it the case that there is only ever a single connection
> talking to the dbus daemon ? if not - it would seem unfortunate to block
> all other writers if a single writer has gone AWOL surely ?

OK, we could also make gdbusprivate.c's write_message() async - that
way your program can survive a remote peer (temporarily?) not
accepting data. So exactly what do we do if g_socket_send_message()
returns ERROR_WOULD_BLOCK? (Wait for a G_IO_OUT condition I suppose)

>        Would you be ok with an approach that strobed the socket poll events to
> wait until there is space to write ?

Yep, sounds good. Of course, we need to change the API of
write_message() so it takes a GAsyncReadyCallback so the worker can
poke the GDBusConnection in case a real error happens (ie. call
_g_dbus_worker_emit_disconnected()).

Perhaps move this feature/bug to bugzilla?

>> Can't say where the SIGTERM is coming from but note that
>> GDBus will scribble on stdout before raising SIGTERM, see
>
>        Sure - so it is GDBus in the code path from
> g_dbus_connection_real_closed - from the path I highlighted.
>
>        It seems that the default is to raise SIGTERM on close there - at
> least, it looks like it is not but the connection comes from:
>
>        get_uninitialized_connection from g_bus_get_sync
>
>      ret = *singleton = g_object_new (G_TYPE_DBUS_CONNECTION,
>                                        ...
>                                       "exit-on-close", TRUE,
>                                       NULL);
>
>        so, it seems the shared singleton connection has this behaviour by
> default. Is that deliberate ? I assume most client users don't want that
> (?).

Yes, it's very deliberate and also how libdbus-1 works. The idea is
that this only happens when the session dbus-daemon(1) instance is
killed. It's a way to ensure that no stale processes are left in your
process.

(Note that GDBusConnection objects that are not the shared singleton
has :exit-on-close set to FALSE though. E.g. for peer-to-peer
connections you don't get this behavior.)

Cheers,
David