[prev in list] [next in list] [prev in thread] [next in thread]
List: gtkmm
Subject: Re: gtkmm-list Digest, Vol 196, Issue 3
From: Benjamin Quinn via gtkmm-list <gtkmm-list () gnome ! org>
Date: 2020-09-13 13:35:28
Message-ID: CAL7GaSnCpzzyYzYNq0dnTPJhGLqVhmhQZtVxtzUmYMniExX3OQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Ok, yeah, I guess I didn't quite make it that far in the docs!
Nice find :)
I have updated my test project to use signal_idle().connect_once(). That
appears to work as expected, no need for queues!
I suppose it could still be worth using a queue if you were planning on
streaming back data from another thread, instead of just using the thread
as a worker that triggers its own callbacks.
https://github.com/Blquinn/idlequeue/tree/sig-idle
I think it would also be a good idea to have an example of using
connect_once in the docs, I think the callback method is probably quite a
common workflow.
-Ben
On Sun, Sep 13, 2020 at 8:00 AM <gtkmm-list-request@gnome.org> wrote:
> Send gtkmm-list mailing list submissions to
> gtkmm-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
> or, via email, send a message with subject or body 'help' to
> gtkmm-list-request@gnome.org
>
> You can reach the person managing the list at
> gtkmm-list-owner@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gtkmm-list digest..."
>
>
> Today's Topics:
>
> 1. Re: Invoking GTK main thread from other threads (Daniel Boles)
> 2. Re: Invoking GTK main thread from other threads (Daniel Boles)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 12 Sep 2020 14:40:52 +0100
> From: Daniel Boles <dboles.src@gmail.com>
> Cc: gtkmm-list <gtkmm-list@gnome.org>
> Subject: Re: Invoking GTK main thread from other threads
> Message-ID:
> <CAKChMKOcYF1tUzFkwrEf4=
> zWhr_46r4ufrJZ3-BmJU8TrKPOXQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Yeah, that doc did it for me: it seems that sigc++ makes glibmm less thread
> safe than GLib itself here. So I have some rewriting to do!
>
> Thanks for the links and discussion :-)
>
> > Although glib is itself thread-safe, any glibmm wrappers which use
> libsigc++ will not be. So for example, only the thread in which a main loop
> runs should call Glib::SignalIdle::connect(),
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/8a27bc95/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 12 Sep 2020 14:44:25 +0100
> From: Daniel Boles <dboles.src@gmail.com>
> To: gtkmm-list <gtkmm-list@gnome.org>
> Subject: Re: Invoking GTK main thread from other threads
> Message-ID:
> <CAKChMKN92giz6NNq6dK=
> HQ_7syRBXorSdd61poPXMCxOtSBSVg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Or maybe it's not so bad, since I usually only need to do things once, when
> the main thread resumes, and that sounds OK. Phew! :-D
>
> > The connect*_once() variants, Glib::SignalIdle::connect_once(),
> Glib::SignalTimeout::connect_once(),
> Glib::SignalTimeout::connect_seconds_once(), are thread-safe for any case
> where the slot is not created by a call to sigc::mem_fun() which represents
> a method of a class deriving from sigc::trackable.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/0184a5e0/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
> ------------------------------
>
> End of gtkmm-list Digest, Vol 196, Issue 3
> ******************************************
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>Ok, yeah, I guess I didn't quite make it that far in the \
docs!</div><div><br></div><div>Nice find :)</div><div><br></div><div>I have updated \
my test project to use signal_idle().connect_once(). That appears to work as \
expected, no need for queues!</div><div><br></div><div>I suppose it could still be \
worth using a queue if you were planning on streaming back data from another thread, \
instead of just using the thread as a worker that triggers its own \
callbacks.<br></div><div><br></div><div><a \
href="https://github.com/Blquinn/idlequeue/tree/sig-idle">https://github.com/Blquinn/idlequeue/tree/sig-idle</a></div><div><br></div><div>I \
think it would also be a good idea to have an example of using connect_once in the \
docs, I think the callback method is probably quite a common \
workflow.<br></div><div><br></div><div>-Ben<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 8:00 AM \
<<a href="mailto:gtkmm-list-request@gnome.org">gtkmm-list-request@gnome.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send gtkmm-list \
mailing list submissions to<br>
<a href="mailto:gtkmm-list@gnome.org" \
target="_blank">gtkmm-list@gnome.org</a><br> <br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mail.gnome.org/mailman/listinfo/gtkmm-list" \
rel="noreferrer" target="_blank">https://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gtkmm-list-request@gnome.org" \
target="_blank">gtkmm-list-request@gnome.org</a><br> <br>
You can reach the person managing the list at<br>
<a href="mailto:gtkmm-list-owner@gnome.org" \
target="_blank">gtkmm-list-owner@gnome.org</a><br> <br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gtkmm-list digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Invoking GTK main thread from other threads (Daniel Boles)<br>
2. Re: Invoking GTK main thread from other threads (Daniel Boles)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 12 Sep 2020 14:40:52 +0100<br>
From: Daniel Boles <<a href="mailto:dboles.src@gmail.com" \
target="_blank">dboles.src@gmail.com</a>><br>
Cc: gtkmm-list <<a href="mailto:gtkmm-list@gnome.org" \
target="_blank">gtkmm-list@gnome.org</a>><br>
Subject: Re: Invoking GTK main thread from other threads<br>
Message-ID:<br>
<CAKChMKOcYF1tUzFkwrEf4=<a \
href="mailto:zWhr_46r4ufrJZ3-BmJU8TrKPOXQ@mail.gmail.com" \
target="_blank">zWhr_46r4ufrJZ3-BmJU8TrKPOXQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Yeah, that doc did it for me: it seems that sigc++ makes glibmm less thread<br>
safe than GLib itself here. So I have some rewriting to do!<br>
<br>
Thanks for the links and discussion :-)<br>
<br>
> Although glib is itself thread-safe, any glibmm wrappers which use<br>
libsigc++ will not be. So for example, only the thread in which a main loop<br>
runs should call Glib::SignalIdle::connect(),<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/8a27bc95/attachment.html" \
rel="noreferrer" target="_blank">https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/8a27bc95/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 12 Sep 2020 14:44:25 +0100<br>
From: Daniel Boles <<a href="mailto:dboles.src@gmail.com" \
target="_blank">dboles.src@gmail.com</a>><br>
To: gtkmm-list <<a href="mailto:gtkmm-list@gnome.org" \
target="_blank">gtkmm-list@gnome.org</a>><br>
Subject: Re: Invoking GTK main thread from other threads<br>
Message-ID:<br>
<CAKChMKN92giz6NNq6dK=<a \
href="mailto:HQ_7syRBXorSdd61poPXMCxOtSBSVg@mail.gmail.com" \
target="_blank">HQ_7syRBXorSdd61poPXMCxOtSBSVg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Or maybe it's not so bad, since I usually only need to do things once, when<br>
the main thread resumes, and that sounds OK. Phew! :-D<br>
<br>
> The connect*_once() variants, Glib::SignalIdle::connect_once(),<br>
Glib::SignalTimeout::connect_once(),<br>
Glib::SignalTimeout::connect_seconds_once(), are thread-safe for any case<br>
where the slot is not created by a call to sigc::mem_fun() which represents<br>
a method of a class deriving from sigc::trackable.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/0184a5e0/attachment.html" \
rel="noreferrer" target="_blank">https://mail.gnome.org/archives/gtkmm-list/attachments/20200912/0184a5e0/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gtkmm-list mailing list<br>
<a href="mailto:gtkmm-list@gnome.org" target="_blank">gtkmm-list@gnome.org</a><br>
<a href="https://mail.gnome.org/mailman/listinfo/gtkmm-list" rel="noreferrer" \
target="_blank">https://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br> <br>
<br>
------------------------------<br>
<br>
End of gtkmm-list Digest, Vol 196, Issue 3<br>
******************************************<br>
</blockquote></div>
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic