Re: [gtkmm] Concurrency with gtk/gtkmm

On Tue, 2002-11-12 at 15:01, Enrico Costanza wrote:

> So, does that mean that only one idle function per time is allowed in gtk?

Most certainly not. Gtk+ itself executes many events that need not be
done right now over the event loop, using different priorities for the
coorrect order of execution. 

I figure that having two idle functions in a programm is a bit silly
tho, as they can be converted to one that calls the other two...

> 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.
> I managed to have the first 2 running smootly, but I had lots of 
> problems when I tried to add the 3rd one.

For most types of communication between programs there is some way to
add this communication to the main event loop of Gdk. If the external UI
responds via pipes/sockets, create an IOSource for it. If it uses X,
ditto, then use XNextEvent() (and XFlush() occasionaly...). If it uses
signals, add a high-priority idle function. If you will need to poll a
memory region (direct hardware access or mmap()ed area), install a
timeout function. And so on...

> >>Also what should I then use to have 2 or more processes in parallel?
> >>I have seen that glib supports threads, and I have also seen POSIX.
> >>Is there any (dis)advantage in using one or the other with gtk/gtkmm?
> >>(I have read that gtk is not thread safe, what does this mean in practice?)
> > 
> > 
> > This means that you should not call Gtk+ (and therefore Gtkmm) code from
> > two threads at the same time. You *can* have a thread for handling the
> > UI and one (or more) for the other processing you need to do.
> > 
> > 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, no, no. Glib's thread support is just a wrapper for ther platform's
thread support. 

> My supposed bottleneck is at about 120ms, so this should be my target.
> Thanks again,
> Enrico Costanza

That is quite lax, you should'nt have any problems.


Tassos Bassoukos

Never be afraid to try something new. - Remember that amateurs built
the ark. Professionals built the Titanic. --  unknown 

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]