Re: GDBus socket code ...
- From: Michael Meeks <michael meeks novell com>
- To: David Zeuthen <zeuthen gmail com>
- Cc: Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: GDBus socket code ...
- Date: Wed, 11 Aug 2010 14:19:05 +0100
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 ...
> > 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 ?
> Anyway, I wonder if it's enough to just switch the socket into
> blocking mode. Can you try that? (I think this is safe to do this
> because we have our own reading routines in gdbusprivate.c,
> _g_socket_read_with_control_messages(), that doesn't care if the
> socket is in blocking mode or not...)
Might work; my only concern would be the case where there are multiple
users of shared_thread_func's main-loop, and others get blocked.
Would you be ok with an approach that strobed the socket poll events to
wait until there is space to write ?
> 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
(?).
Thanks,
Michael.
--
michael meeks novell com <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]