mh.. guess P is an actuall pointer to PMC, in that case forget that part.. :) Stephane
On Mon, Aug 23, 2004 at 11:15:03PM +0200, Stephane Peiry wrote: [signatures question gone] > > *If* that is solved then the next problem is of course that by calling > > gtk_main() the GTK event loop is running. That means, while > > Parrot_callback_C() would get called, the callback fuction itself > > wouldn't get run because Parrot isn't executing any code at that point. > > Parrot is stuck in the NCI call to gtk_main(). > > mh.. thats was not the way I understood callbacks were implemented. > I mean understood from this thread (*): > > [1] pdd16 states: > Hand over control to the external library. IT IS > IMPORTANT THAT THE INTERPRETER YOU ARE CALLING BACK > INTO IS NOT ACTIVE WHEN THE CALLBACK IS MADE! > As we don't know, when the callback is invoked, my scheme uses an event > so that its safe to run the PASM code. > > that callbacks were indeed installed through an event (that is on its own > thread) so that it wouldnt block nomatter what parrot would be doing at a > given point (say it invoked some long running function in a lib :) unless > there would be a lock on the user data itself. > > 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). Or maybe run it in its > own thread if the event threads are not enought? > Thanks, > Stephane
