Hi,
On Mon, Jun 25, 2012 at 12:52:35AM +0200, Marek Denis <marek at
octogan.net> 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
callback).
Now, if I make a code like:
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)
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
[[email protected]]
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
