Calling ev_async_send() from multiple threads.

Marek marek at
Tue Jun 26 12:00:57 CEST 2012


On Mon, Jun 25, 2012 at 12:52:35AM +0200, Marek Denis <marek at> wrote:
>> different threads is a safe technique. However I am not really sure,
>> whrther those calls will trigger callback functions the exact number 
>> of

>They don't. It works like any other watcher, such as timers or I/O
>watchers, it's only invoked as soon as possible.

>> however I would like to be able to make a callback like:

>The extra emptyness test of your queue ought to be way cheaper than 
> the
>atomic counter libev would have to implement.

OK, I think some explanation  would be quite useful for me.
What actually happens if something like this happens:

A callback function A_cb() is called upon triggering the async watcher. 
The A_cb() locks a mutex and takes some "command package" from the 
shared queue. The commands are added by other threads, so the access 
needs to be synchronized. Now, A_cb() takes the command and calls 
another function B_notify() that adds some pointers to objects B waiting 
for work done in a thread. Also, B_notify() triggers B's async watcher 
telling him "go ahead, here is new data for you".

So, here is the situation, where calling one callback function (A_cb) 
will end up in triggering another watcher (and thus call another 

Now, if I make a code like:

Here is that A_cb():

   while(!queue.empty()) {
     data = get_data_from_hared_queue();

and B_notify(data) will look like:

appropriate_queue = choose_queue_from_object();
this->async_watcher.send(); (let's imagine it runs iterate_cb() 

Now my question is if the flow->B_notify() will end only after the 
iterate_cb() function returns (so the iterate_cb will be running with 
mutex still locked!)? Or rather flow->B_notify() is called, inside the 
B_notify the watcher is triggered (but the callback doesn't launch), 
B_notify() returns,the mutex is unlocked and only after that libev runs 
iterate_cb as a this->async_watcher callback ?


Marek Denis
[marek at]

More information about the libev mailing list