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

Dies ist eine mehrteilige Nachricht im MIME-Format.
--===============6547936259100931909==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



--===============6547936259100931909==
Content-Type: multipart/alternative; boundary="=_alternative 004099F0C1257E66_="

Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 004099F0C1257E66_=
Content-Type: text/plain; charset="US-ASCII"

Hi Simon,

thank you :)

> In the specific case of GDBus it is actually OK to use the same
> GDBusConnection from different threads.

Yes, it's also documented.

> As a general rule, you should never do anything with a pointer if you
> cannot know that the object it points to is not going to be freed by
> another thread. 

Oh, you are right! Somehow, I was totally mixed up! But I guess, I figured 
out what disturbed me: 
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);

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?

Best regards
Jean-Pierre

--=_alternative 004099F0C1257E66_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi Simon,</font>
<br>
<br><font size=2 face="sans-serif">thank you :)</font>
<br>
<br><tt><font size=2>&gt; In the specific case of GDBus it is actually
OK to use the same<br>
&gt; GDBusConnection from different threads.</font></tt>
<br>
<br><tt><font size=2>Yes, it's also documented.</font></tt>
<br>
<br><tt><font size=2>&gt; As a general rule, you should never do anything
with a pointer if you<br>
&gt; cannot know that the object it points to is not going to be freed
by<br>
&gt; another thread. </font></tt>
<br>
<br><font size=2 face="sans-serif">Oh, you are right! Somehow, I was totally
mixed up! But I guess, I figured out what disturbed me: &nbsp;</font>
<br><font size=2 face="sans-serif">For sure it is a bad idea to use the
object, if the timing is like this:</font>
<br>
<br><font size=2 face="sans-serif">1. g_object_unref(conn);</font>
<br><font size=2 face="sans-serif">2. g_dbus_connection_emit_signal(conn);
=&gt; Object is already freed. User deserves the crash ;)</font>
<br>
<br><font size=2 face="sans-serif">But what is, if the timing is like this:</font>
<br>
<br><font size=2 face="sans-serif">1. g_dbus_connection_emit_signal(conn);</font>
<br><font size=2 face="sans-serif">2. g_object_unref(conn);</font>
<br>
<br><font size=2 face="sans-serif">I haven't seen that the &quot;g_dbus_connection_emit_signal&quot;obtains
a reference to the connection! </font>
<br><font size=2 face="sans-serif">Shouldn't it do so, to be sure that
the connection is not freed &quot;during&quot; the call?</font>
<br>
<br><font size=2 face="sans-serif">Best regards</font>
<br><font size=2 face="sans-serif">Jean-Pierre</font>
<br>
--=_alternative 004099F0C1257E66_=--

--===============6547936259100931909==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gnome-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

--===============6547936259100931909==--