Well, still about getting callbacks to work on GTK, thaught that before going for this:
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote: > >Otherwise, already thaught of actually unrolling the gtk_main function > >and have it handled/implemented within parrot directly (mainly gtk_main > >simply loops and waits on the gtk event queue). > > That's the way to go. giving a try to the idea of "putting gtk_main on its own thread" would be worth.. unless theres a thourough warning with a "dont do that" msg in it? Attached is the a really "quick hack" that uses nci again to actually start gtk_main on its own thread, rather than calling it directly and this works nicelly for what I tested :) The only issue I see atm is if parrot wants to call the callback it- self while in the "waiting for callback loop", mean it would run into some race conditions if for some reasons parrot invokes the callback, and somebody triggers the callback via gtk..? While thinking about this, isnt the current callback implementation having this issue, or how does it handle this? say if the callback function increments an int value passed in and then prints it, it should always print 1 (if 0 was passed) whereas afaik it might sometimes print 0 or 2 (depending on when the external lib and parrot would be calling in). Is this dealt with explicitly? ie. parrot executing a function (the callback) in a single go? Or is it meant to be up to the programmer, like "you shouldnt call it yourself", or lock your data or else? Thanks, Stéphane
gtk.callbacks.tar.gz
Description: GNU Zip compressed data
