Re: Re: Clarification on threading
Tani Hosokawa <tani <at> tanihosokawa.org>
2008-09-04 16:50:10 GMT
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.
> 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
>>> 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: jhohle <at> godaddy.com <mailto:jhohle <at> godaddy.com>
>>> pstn: 480.505.8800_.4324
>>> voip: 4324
>>> cdma: 480.323.5799
>>> Libevent-users mailing list
>>> Libevent-users <at> monkey.org
>> Libevent-users mailing list
>> Libevent-users <at> monkey.org