On Mon, Jan 28, 2008 at 01:22:42PM -0700, Tony Arcieri <[EMAIL PROTECTED]>
wrote:
> In fact, I could envisage that this functionality (signaling a loop
> > asynchronously) could become part of libev proper if there is demand, as
> > libev already has to handle asynchronous signals at leats in one loop
> > and therefore needs the mechanism already (and that way it could e.g. be
> > optimised by using an eventfd or other os-specific means).
> >
>
> Something like this would be extremely useful for sending asynchronous
> messages across threads. Rubinius does something like it already, and I'll
> be adding something like it to Revactor soon. If you did implement some
> sort of cross-thread signal watcher I'd probably end up using it.
Ok, counted, lets see if I can find time.
The proposed interface would be something like:
struct ev_async {
// nothing to see, except maybe a
sig_atomic_t signal;
// (where we assume that sig_atomic_t is also threadsafe :)
};
void ev_async_send (ev_async *w, sig_atomic_t signal);
the async_send would be callable, well, asynchronously. the problem is
getting it fast (as in O(1)), but I guess a O(n) solution in the number of
async watchers might do (and could always be improved).
It would also avoid any queueing issues by not supporting it, so signaling
a aignal n times might result in <= n invocations (and maybe this is why
the sig_atomic_t member might not be there).
Also, the uer would be responsible to only run ev_async_send on started
watchers etc. etc.
all that would piggypack nicely on top of the existing signal handling.
feedback from people on this would be nice.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
