On Thu, Dec 22, 2011 at 11:47:19AM +0800, freebsdj <[email protected]> wrote: > Sorry for the format, I didn't wrap the long line.
You didn't, but your programs did :=) > 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(). I am not sure what you mean, the syntax of assert() requires some code to be used inside. It's impossible not to embed some code inside an assert. Maybe you should describe in more detail what you mean with "code" and embedded into an assert. > Additionally, ev_run() is a blocking function, how to protect > threads to avoid running this function concurrently? A pthread mutex will do fine - all thread libraries ought to some something like a mutex or a semaphore for this purpose. > 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. Check your code, you are not calling it in any way that is "one by one" - either you call it concurrently, or you recurse in acquire/release. If your really disagree, then find the only assignment to EVBREAK_RECURSE in the code and explain how it survives the assignment immediately afterwards. > BTW: it seems that ev_pool.c & ev_select.c is needed while > embedding, how can we remove the 2 files? Don't compile with poll and/or select backends, although this is really not recommended. See the documentation for details on how to disable single backends. > On Thu, Dec 22, 2011 at 3:31 AM, Marc Lehmann <[email protected]> wrote: Please don't quote large amounts of text without replying to them. It's just wasting a lot of time to go through, trying to catch the hidden messages you implanted :) > 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? Mostly to check on "abusing" recursion (which usually happens in only multithreaded environments), but the check also catches concurrent calls with high probability, so it is quite useful for this as well. But implemented it was indeed only at the time where acquire/release callbacks where implemented, so catching concurrent ev_run calls is a welcome side effect only. -- 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
