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
