my bug or libev's? when multi-thread and multi-loop
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
Re: my bug or libev's? when multi-thread and multi-loop
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
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
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