dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
Whatever you'll try the current scheme is not compatible with this GTK callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
Parrot stuffs the interpreter and the Sub PMC into user_data and unpacks that when the callback should run. This is based on the assumption that the function that establishes the callback takes a (void *) pointer and *does not* care, what the pointer is pointing to. GTK obviously takes either a NULL (which isn't usable with Parrot) or a GObject* only.
I can currently only imagine to put the needed information "into" the function pointer, which is obviously not that easy:
struct callback_info {
Interp *interpreter;
PMC *sub;
opcode_t code[1];
}GTK gets the address of C< code >). At code[0] ... code[n] is a function (created NCI-like on-the-fly) that extracts the interpreter (code[-2]) and the Sub (code[-1]) and calls the C function inside Parrot that actually triggers the call of the callback.
The problem is of course that it would need (minimal) JIT support for every platform.
(as I understand it, by having "p" on the signature for the user data,
gtk gets what it wants, a pointer to the user data,
No. 'p' means that GTK get's, what PMC_data(user_data) is pointing to.
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!
That's IMHO a restriction we hardly can fulfill. This is the reason for:
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.
Yes. But draining the event queue still needs a running Parrot runloop. Only because the event system is running its own thread does not mean, that we just can run the code at any time or in parallel with the foreground runloop.
Callbacks or timer event subroutines are always run by the interpreter that created that event. This needs a running Parrot.
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.
Thanks, Stephane
leo
