Actually, I'm using evhttp for processing the requests. Pretty much
stock libevent if you're using the latest version, and only minor
thread-safety issues in the really old versions and then only for
outbound HTTP connections.
Chris Ross wrote:
Thanks for the information.
Since the first post, I have implemented a dedicated listening/reading
thread with libevent with a pool of worker threads. The incoming
requests are read, packaged and handed over to a thread (knows nothing
of libevent) which will then perform the request and then write the
data back and go back to sleep. Seems to work nicely. It did require
me to write my own http server but hey - such is life.
Chris
On 4 Sep 2008, at 17:20, Tani Hosokawa wrote:
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
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
