Re: Antwort: Re: SIGTRAP when sending signal on closing dbus connection

On 16/06/15 12:45, Jean-Pierre Bogler continental-corporation com wrote:
For sure it is a bad idea to use the object, if the timing is like this:

1. g_object_unref(conn);
2. g_dbus_connection_emit_signal(conn); => Object is already freed. User
deserves the crash ;)


But what is, if the timing is like this:

1. g_dbus_connection_emit_signal(conn);
2. g_object_unref(conn);

How can you guarantee that the timing is always going to be like this,
i.e. that thread 1 always "wins the race"?

If the answer is a mutex or something, extend the scope of the mutex to
protect g_d_c_e_s() and you're fine.

If the answer is "I can't guarantee that", then you still have a bug (a
classic race condition), and still deserve the crash :-)

I haven't seen that the "g_dbus_connection_emit_signal"obtains a
reference to the connection!
Shouldn't it do so, to be sure that the connection is not freed "during"
the call?

Not really. That would make simple code where the object is not shared
between threads slower (taking a reference is not free - it's an atomic
operation which flushes CPU caches), and the only situations in which it
helps you to not crash are those where you already have a race condition
that will sometimes crash your program anyway.

If some code has broken reference-counting and is sometimes going to
crash, I'd prefer it to crash more often, so that its developer can find
and fix it.

Simon McVittie
Collabora Ltd. <>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]