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

[Marc Lehmann]

On Thu, Dec 22, 2011 at 11:47:19AM +0800, freebsdj <freebsdj at gmail.com> 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 <schmorp at schmorp.de> 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
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\