GNOME Bugzilla – Bug 61265
g_signal_connect to a GAsyncQueue
Last modified: 2011-02-18 16:13:49 UTC
A signal is being emitted in one thread, but i need the handler called in a different thread. i'd like to have a g_signal_connect_async_queue API, which: 1 marshals the signal emission into a structure 2 pushes the frozen signal onto a async queue 3 and something like 'g_signal_emission_dispatch', to do a try_pop on the queue and then invoke the signal Of course this would only work for signals which don't return anything. All that's really needed to implement this is some minor reorganization of the code in gsignal.c and then exporting a few APIs.
Created attachment 5704 [details] my temporary work-around
if you don't need the marshalling, main loop idles can be an easy way of getting execute-in-a-different-thread functionality.
If i don't need the marshalling? The signals are being emitted by a library. Assume i can't change the library. To get the signal into the main thread, i have to receive it, marshal it *again*, add it to an asyncqueue, unmarshal it *again*, and call the real handler.
It should be decided whether this is a feature that will be included in upcoming Glib releases.
(In reply to comment #0) > A signal is being emitted in one thread, but i need the handler called in a > different thread. i'd like to have a g_signal_connect_async_queue API, which: beast implements this to some extend in order to be able to serialize and dispatch signal emissions from one process to another. most of this functionality is implemented by the functions bclosure_marshal() and bglue_proxy_request_notify() in: http://svn.gnome.org/viewsvn/beast/trunk/bse/bseglue.c?rev=3440 > 1 marshals the signal emission into a structure > the basic idea implemented in beast is to create and connect a GClosure with a custom marshaller, this marshaller gets all the GValues required by the signal emission already properly stacked up in an array. from there on, it's basically just a matter of copying or serializing the values to pass them on for custom emission code later on. > 2 pushes the frozen signal onto a async queue > > 3 and something like 'g_signal_emission_dispatch', to do a try_pop on the > queue and then invoke the signal > > Of course this would only work for signals which don't return anything. unfortunately i think this can't be gotten to work 100% perfectly for the generic case. the problem here is once again the boxed types we use. suppose a gtk thread sets up a list/hashtable/etc. and passes it as a boxed typed into a signal emission. after the emission finished, the structure is modified and reused for something different. at that point, asyncronous evaluation of the "copied" GValue array will run into problems, because GValues aren't perfectly deep copyable due to lack of knowledge about boxed type internals, deep copy ability of objects and opaque types passed as GPointer. serialization of course has the same problems, see: http://bugzilla.gnome.org/show_bug.cgi?id=157734 (Serialization Proposal) > All that's really needed to implement this is some minor reorganization of > the code in gsignal.c and then exporting a few APIs. as the beast code shows, there are no libgobject modifications required to get this going/supported in principle. however, any implementation will have to either: 1- restrict itself strongly to perfectly deep copyable values (beast does this); 2- block within the marshaller until the remote or "asyncronous" emission completed. (1) is probably not generic enough to be of general use in libgobject, so unless a strong case is made for its inclusion, i'd rather leave implementation of custom dispatch mechanisms to third party projects that need it. and while (2) would work for the general case (also properly handling return value accumulation), it's not clear to me that this is something libgobject users would generally need. i.e. i'd like to see requests with use cases before adding such a thing to libgobject.