Re: [gtkmm] Concurrency with gtk/gtkmm



On Mon, 2002-11-11 at 20:57, Enrico Costanza wrote:

[snip]
> Up to now I have used idle function successfully to avoid GUI to freeze. 
> I have tryed to use 2 idle functions hoping that this would simply and 
> efficently put the two functions in parallel execution, but this does 
> not work. One of the two is blocked. I have tryed a variety of values 
> for the priority of the two (both 0, both a higher number, one lower and 
> one higher value..).
> 
> First of all I wander: why is this not working?

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. 

As an example, say you have a process that goes on and on I (say,
calculating the numbers of pi), and a button called "Stop". The button,
when clicked, will set a variable named f.e. "stop_calculations".
In the idle function, the code checks this variable, and if set will
return "false" to remove itself as an idle handler. If not set, it will
calculate the next digit of pi and return true, to remain as an idle
handler..

> 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.

> Is there any other option that i should consider?
> (for this particular situation of monitoring an input, would it be worth 
> to consider implmenting my own set of signals & handlers?)

It depends on your timing constraints. Are 10 ms delays acceptable?
100ms?  100us?

> Thank you very much in advance,
> Enrico Costanza


HTH,
Tassos

-- 
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]