Re: Antwort: Re: SIGTRAP when sending signal on closing dbus connection
- Date: Tue, 16 Jun 2015 13:23:12 +0100
- From: Simon McVittie <simon.mcvittie@xxxxxxxxxxxxxxx>
- Subject: Re: Antwort: Re: SIGTRAP when sending signal on closing dbus connection
On 16/06/15 12:45, Jean-Pierre.Bogler@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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.
Collabora Ltd. <http://www.collabora.com/>
gtk-devel-list mailing list