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 <[email protected]> wrote: > On Thu, Dec 22, 2011 at 01:58:52AM +0800, freebsdj <[email protected]> > 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 > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ >
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
