Re: my bug or libev's? when multi-thread and multi-loop

2008-12-02 Thread Marc Lehmann
On Tue, Dec 02, 2008 at 04:46:32PM +0800, CodeAll [EMAIL PROTECTED] wrote:
 queue. Each of the worker has a ev_base_new(0).

What is an ev_base_new(0)? and which version of libev are you trying
this with?

 1. I kill -SIGSEGV the process, gdb it, found it's busy on epoll_wait()

The process still exists after SIGSEGV? that means you have a signal
handler for it - what does it do?

 6. I guess, that maybe something wrong when i using libev in mutil-thread
 env, or some fd are wrongly closed, or some fd are missing but events
 continue coming.

That's most likely a bug in your program - make sure you never call
functions on the same event loop from different threads, OR use locking.

There are also other rules to follow, such as stopping your event watchers
before freeing them etc., but this probably isn't the problem here.

 Sorry for my english.

I find your english quite good :)

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  [EMAIL PROTECTED]
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev


Re: my bug or libev's? when multi-thread and multi-loop

2008-12-02 Thread Marc Lehmann
On Tue, Dec 02, 2008 at 04:59:11PM +0800, CodeAll [EMAIL PROTECTED] wrote:
 1. a little like http://lists.schmorp.de/pipermail/libev/2008q4/000453.html,
 but i tried poll backend, has problem too

Not at all, actually.

 2. when i generate a lot of request from 10 client, the server choose to not
 keepalive(one request per connection), but the system is reusing fd. Like,
 fd = 14 are closed, after a well, fd = 14 are used again. I see this in
 io_cb()'s debug info and strace's epoll_wait(xxx)

Not sure whwt the relevance of that is, but in general, you have to stop a
watcher when you close a fd.

The documentation epxlains this in detail.

However, this would not cause the problems you see.

It really looks much more like you accessed the same event loop form
multiple threads, or had another bug in your program, such as not
initialialising the file descriptor number properly.

Without an example program showing the issue or a minimal amount of
additional info (libev version, strace), there is nothing more that I cna
say.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  [EMAIL PROTECTED]
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev


Re: my bug or libev's? when multi-thread and multi-loop

2008-12-02 Thread CodeAll
More info:
1. a little like http://lists.schmorp.de/pipermail/libev/2008q4/000453.html,
but i tried poll backend, has problem too
2. when i generate a lot of request from 10 client, the server choose to not
keepalive(one request per connection), but the system is reusing fd. Like,
fd = 14 are closed, after a well, fd = 14 are used again. I see this in
io_cb()'s debug info and strace's epoll_wait(xxx)

On Tue, Dec 2, 2008 at 4:46 PM, CodeAll [EMAIL PROTECTED] wrote:

 Hi, Everyone:
 I use libev in my network server.
 I have one main thread with default event loop for bind/listen/accept, then
 dispatch the cilent fd to 4 worker thread, using ev_async and a blocking
 queue. Each of the worker has a ev_base_new(0). Worker monitor the client
 fd's EV_READ and EV_WRITE, parsing data into data structure, write response
 back, in ansyc-callback way.

 Everything goes will when startup. After several client connections, the
 CPU are higher and higher. Something must be wrong.
 1. I kill -SIGSEGV the process, gdb it, found it's busy on epoll_wait()
 2. I use strace/lstrace -f -p the process, it's also busy on epoll_wait()
 3. After a lot of client connections, libev abort with: libev: cannot
 allocate 2147479536 bytes, aborting.
 4. the epoll_wait() somethings are empty, somethings has 1 or 2 or more
 active fd's POLL_IN or POLL_OUT not handled, but i haven't receive any
 callback call
 5. The one-thread version is ok.
 6. I guess, that maybe something wrong when i using libev in mutil-thread
 env, or some fd are wrongly closed, or some fd are missing but events
 continue coming.

 Sorry for my english.

 Could anyone help?




___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev