Re: GEvent - Proposal for a new threading structure for GLib

Olexiy Avramchenko wrote:

On 11/17/06, Matthew Barnes <mbarnes redhat com> wrote:
I've attached a patch that implements and documents GEvent.  It closely
mimics the Python class, so I won't bother describing the API here.

Is GCond not suitable for this purpose?
Yes it is, never the less I have to agree (as someone finding themselves
repeatedly rewriting the same code segments for that purpose) that it is not an
ideal api for message passing/handling.

One should be able to do something like:
g_message_send (destination[null for broadcast], "messagename", msg_size, msg_data);

so that a message handler in another thread recieves the message for "messagename",
or a little more high-tech but also usefull would be:
g_message_sync_call (destination[null for an implicit call], "messagename",
                                       msg_size, msg_data,
                                       timeout, &retsize, &retdata);
that would ensure that the thread that handled the message did so inside "timeout" milisecs, and to retrieve the return value from the thread that honored the message.

The problem I think is that writing up a simplified "only gonna work with gthread" messaging system might just be neglecting the need for a real IPC, that would have the same kind of friendly apis we all need (I'm not reading those threads closely but isnt that what all the dbus rage is all about ?)... I guess ideally it should also work "distributed", a vague buzzword, I mean that g_message_send() should not nescisarily be restricted to processes running on the same host (there should be connections to a domain

Well my 2 cents was a little vague and rattled but the point remains, the apis I mentioned were also strictly a figure of speach to demonstrate the type of functionality
ultimately needed for messaging across threads/processes/hosts.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]