Not sure if this is the right list but here goes.
Tristan Van Berkom <[EMAIL PROTECTED]> recently wrote:
"Maybe its just my personal opinion but I always prefer letting the main
loop do its thing and not hack around it by adding:
"while (events_pending) iteration_do();"
sprinkles here and there, I think its important to write your code in
short callbacks and return to the main loop as much as possible."
I need to "eliminate" work from GTK callbacks, I'm not sure how
to do this. Probably a hard question.
My system provides fibres (cooperatively multiplexed threads) which
I wish to associate with widgets. A fibre is basically a C++ class
object with a resume() method. In theory, a GTK callback would
invoke the resume method repeatedly until the fibre 'blocks'
then return. This is what I am doing currently.
Unfortunately this is only a first order solution. Fibres communicate
by sending messages along channels. A scheduler loop is used to
resume fibres with pending messages. When all the fibres are
waiting, the loop blocks on condition variable and waits for
asynchronous events managed by other threads to provide
some new data and reactivate them.
What I think I need to do is this.
* Run gtk in a pthread
* Each "significant" callback sends a message to the fibre scheduler
* The callback then blocks the GTK thread
* Eventually some fibre will complete the work required
for the callback and send a message
* the GTK thread receives the message, unblocks, and continues on
A "significant" callback is one which has to do serious work.
An example of an "insignificant" callback is one which, for
example, reads a keyboard or mouse event, posts it into
a queue, and returns. Such events can be handled by ordinary
callbacks.
Posting stuff into Gtk (so the event loop handles it)
seems easy. Inverting the event loop seems very hard.
My system mechanically translates source code into inverted
form which is then driven by a scheduler. The only way
I can see to control invert Gtk loop seems to be to
run it in a thread. The effect will be to lock up Gtk
whilst my system's thread does its job, then swap
control back. One side effect of this is that re-entered
Gtk main loops would be problematic.
Anyone hints from people that know the inner gory details
of event management would be welcome. The software has
to work on Windows (as well as Linux, various Unicies, and OSX)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
