On 16/06/15 12:45, jean-pierre.bog...@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 ;)
Sure. > 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. <http://www.collabora.com/> _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
