FWIW, I have written a similar system which uses a dedicated accept
thread and a pool of read/write threads (1 per CPU) and it works fine
with over 20000 concurrent connections. Using a thread per connection
is the exact opposite of what event based processing is intended for.
Jonathan Hohle wrote:
I have recently added some code to do the following: - Setup a worker
pool of threads that sit waiting on a condition variable. - The main
thread takes the request struct and puts it in to the queue of a
thread, wakes the thread up and asks the thread to deal with it. -
Main thread returns to even processing. - Thread answers the request
and then goes back to sleep. The problem I have is that it'll process
one request and then stop.
...but I wondered if anyone had any words of wisdom.
I don't know if this helps or not, but I recently set up a app with a
similar architecture. Originally it used a single event base which
handled accepts and reads. I thought: why don't I just separate those
into separate threads (in my case a single accept thread, and multiple
read threads, with round-robin event queuing).
Things went well *until* I had more concurrent connections than I had
reader threads. I banged my head over my locking strategy for several
days, but finally came to the conclusion that
event_add/event_base_loop are not thread safe (at least in libevent
1.4.x).
In the typical case, you're adding events either in an event handler
callback, or before the event loop has begun. In a case with multiple
threads and multiple event loops, there is no clear indication of when
an event is added to the queue. (Someone please correct me if I'm wrong).
I can't find the tab atm, but I have seen some discussion about
multi-threading support being present in trunk. I haven't gotten trunk
to build yet, however. For now I think I'm going to revert to a single
queue, giving priority to read events.
On the other hand, having a per-connection thread with its own event
queue works perfectly fine (in my experience). Under heavy load,
however, you can spawn a lot of threads ;)
Jonathan Hohle
smtp: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
pstn: 480.505.8800_.4324
voip: 4324
cdma: 480.323.5799
<><
------------------------------------------------------------------------
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
