On Wed, Jul 04, 2012 at 04:59:05PM +0200, Jorge <jo...@jorgechamorro.com> wrote:
> if (!ev_async_pending(&watcher)) ev_async_send(EV_DEFAULT_UC_ &watcher);
>
> that expands to:
>
> if (!(+(&watcher)->sent)) ev_async_send(ev_default_loop_uc_ (), &watcher);
>
> In all my background (p)threads...
>
> Should I avoid that if (!watcher.sent) tests then?
If it's inside a lock that locks the event loop, it's fine, otherwise it's
undefined behaviour.
On top of undefined behaviour, it's a classical race condition (if you
check before doing something without a lock you will lose events when the
other thread does something in between).
And on top of that, it's likely to be a time waste as well, as
ev_async_send doesn't make the watcher pending immediately (because libev
can't use a lock either, so can't access the loop data structures).
So, are you _really_ sure you want to use threads? They are hard to
control beasts, and even if they seem to work on your box, races can
easily kill you somewhere else, usually at the most inopportune time.
The rule of thumb of using a lock (or something more complicated) to
access state shared between threads isn't really a rule of thumb: you have
to do it, always. Internalise it! :)
--
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
