Re: [gtkmm] Concurrency with gtk/gtkmm
- From: Paul Davis <paul linuxaudiosystems com>
- To: Enrico Costanza <ec142 york ac uk>
- Cc: Tassos Bassoukos <abas aix meng auth gr>, gtkmm-list gnome org, gtk-list gnome org
- Subject: Re: [gtkmm] Concurrency with gtk/gtkmm
- Date: Tue, 12 Nov 2002 09:09:13 -0500
>> Beacuse you are using two idle functions.
>> You do not need to monitor the user interface, the main loop takes care
>> of that for you atomatically. You just need to create and hook up your
>> idle function, which should do some not too time-consuming processing.
>> You then connect signal handlers to events, which (if that event is
>> triggered) will be called between calls to your idle function.
>
>So, does that mean that only one idle function per time is allowed in gtk?
no.
>That is ok, but my problem is that I need to monitor another (external)
>user interface (not gtk) and process some data at the same time.
>I actually have (or wish to have) 3 things going on at the same: the gtk
>GUI, an external interface and a (sound) processing task.
easily accomplished with threads. possible to accomplish without them.
>I managed to have the first 2 running smootly, but I had lots of
>problems when I tried to add the 3rd one.
you should forget about ever, ever, ever doing sound from a thread
controlled by a GUI toolkit.
startup a new thread for the sound processing task. monitor the
external interface via a file descriptor hooked into the main event
loop (see g_io_* functions). use a pipe to send requests from the
sound thread to the GUI thread (and another to send them the other
way). search the archives for "pipe thread" for more details.
it works. http://ardour.sf.net/ has this architecture.
>> Glib supprts threads and the associated infrastructure, but you will
>> still need to create code that uses them.
>
>Does that mean that Glib is not enough to have concurrency, but that I
>need (for example) Glib in addition to POSIX?
no, you do not. there is no particular reason to use glib threads. in
fact, i would argue that there are good reasons not too, and that you
are better just using the pthreads (P.1003) API, since this a true
cross-platform standard.
>My supposed bottleneck is at about 120ms, so this should be my target.
ardour works with "bottlenecks" of as low as 2.3msec.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]