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]
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
