On Tue, Jun 26, 2012 at 12:00:57PM +0200, Marek <ma...@octogan.net> wrote:
> Here is that A_cb():
>
> mutex.lock()
> while(!queue.empty()) {
> data = get_data_from_hared_queue();
> flow->B_notify(data);
> }
> mutex.unlock();
>
>
> and B_notify(data) will look like:
>
> appropriate_queue = choose_queue_from_object();
> appropriate_queue.add(data);
> this->async_watcher.send(); (let's imagine it runs iterate_cb()
> function)
I assume there is some pthread_mutex_lock/unlock inside
appropriate_queue.add.
Then it looks fine to me.
> 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 ?
I don't really know what iterate_cb is supposed to be, but ev_async_send
is pretty simple and can be called at any time.
It would probably be most efficient to call it outside your lock (as in
your example), but you can also call it inside your lock.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
