This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: how to obtain pthread_suspend
- From: Joël Krähemann <weedlight at gmail dot com>
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Sat, 14 Sep 2013 20:50:41 +0000
- Subject: Re: how to obtain pthread_suspend
- Authentication-results: sourceware.org; auth=none
- References: <1379106662 dot 542 dot 12 dot camel at debianWEED> <52337CB1 dot 9010806 at redhat dot com> <1379159716 dot 4109 dot 7 dot camel at debianWEED> <CAE2sS1jMyKFDm3WuZEzBWz8AAfvhyntU2qsQ-pKD386PVhe3eg at mail dot gmail dot com>
Am Samstag, den 14.09.2013, 13:53 -0400 schrieb Carlos O'Donell:
> On Sat, Sep 14, 2013 at 7:55 AM, JoÃl KrÃhemann <weedlight@gmail.com> wrote:
> > I'll do a work-around but as long I can't suspend/resume the GUI loop,
> > it will block AgsTaskThread. I think that async-signal operations need a
> > point where it is synced else it won't be safe or you are doing some
> > ugly mutices scattered all along the code.
>
> If you have complete control, and you need to suspend and resume at
> specific points then you can use a condition variable.
>
> Signals will work, but if, like you said, you have some
> uninterruptable sections, then you need to use something like a
> condition variable.
>
> Cheers,
> Carlos
Yes there are condition variables because I need to sync the threads.
Syncing isn't the only goal to achieve the application needs realtime
capabilities. And AgsGuiThread does overtake gtk's main loop. And Gtk
iteration function is sometimes greedy that means it doesn't fit into
the time period which causes some real bad latency.
I'm expecting of pthread_suspend that it can reduce the latency.
regards
JoÃl