Is that ev_run()/ev_loop() inhibited in multiple thread of current libev?

[freebsdj]

Many thanks!

Sorry for the format, I didn't wrap the long line.

Actually, the thing confused me is that:
NDEBUG is usually allowed when compiling production
 code, so I suspected that whether it's feasible to
embedded code in assert().

Additionally, ev_run() is a blocking function, how to protect
threads to avoid running this function concurrently?
I don't think this is caused by multi-threaded, because even
I call ev_run() one by one, it crashed also: loop->loop_done
was updated to EVBREAK_RECURSE after first calling.

BTW: it seems that ev_pool.c & ev_select.c is needed while
embedding, how can we remove the 2 files?

On Thu, Dec 22, 2011 at 3:31 AM, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Thu, Dec 22, 2011 at 01:58:52AM +0800, freebsdj <freebsdj at gmail.com>
> wrote:
> > My project is a networking server, I have an assign thread to accept
> > connections and
> > dispatch fd to query threads, both assign thread and query threads are
> > using ev_run()
>
> First, can you properly format your e-mail? It's really
> annoying and
> tiresome to read read text that constantly
> changes
> the line lengths it uses.
>
> > The issue is that it will crash while calling ev_run() in query thread,
> > with the message:
>
> Well, stupid question, are you sure you don't use the same loop in both
> calls to ev_run, without any mutex?
>
> > I noticed that the description in manual: better to create a new ev_loop
> in
> > every thread, but according
> > to my experiences of using libev in 2009, I can do that.
>
> You don't need to create a new loop in every thread, as long as you use
> locking. In general, when using threads, you have to use mutexes or other
> means to protect shared resources. The acquire/release callbacks can help
> you do that.
>
> It is probably far easier to use a loop per thread though, as no locking
> is required on your part then.
>
> > 1. Can I use ev_loop() in multi-threads environment(though not
> preferred)?
>
> No, libev is certainly preferred in multi-threaded environments :)
>
> > 2. Why check the loop->loop_done there?
>
> To catch bugs like the one in your code as early as reasonably possible
> (some assertions exist to check new data structures or code changes, and
> normally get removed over time). Asserts are meant to be a debugging help:
> for example, most functions in libev use assert to do basic parameter and
> data structure checking.
>
> I'd guess the parameter checking is very helpful when developing programs,
> and could easily be left on in production I presume. I certainly donät
> bother switching off assertions in most of my code.


Sorry for the confusing. I agreed that we should use asserts to help us
catch
bugs and debugging. What I mean is: the reason why asserting
loop->loop_done here is to check abusing in multi-threaded or other
situations?


> > 3. If I compiled with -DNDEBUG, all the assert()s are ignored, so it will
> > not crash, but it doesn't seems work
> > correctly. Is that an inappropriate design to put code in assertions?
>
> The rules of C require code to be used in assertions. I suspect other
> languages do, too. Maybe you need to rephrase your question?
>
> If you mean that errors are no longer checked via assert when compiling
> with NDEBUG, then, well, yes, thats the whole point of NDEBUG, to disable
> assertions.
>
> You can enable extra verification via EV_VERIFY - the assertions in libev
> are only there to avoid the worst, and are always low-overhead, while
> EV_VERIFY can result in considerable performance loss.
>
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>      -=====/_/_//_/\_,_/ /_/\_\
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111222/01273a74/attachment.html>