[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Cross-event base interactions



On Tue, Nov 20, 2012 at 5:55 PM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
> Hi folks
>
> We have a case where we are running two parallel threads, each looping on their own event base (we have the libevent thread support enabled). Even though the two bases are running in separate threads, however, we see an impact on response time - i.e., if we run only one thread, events in that event base are serviced faster than when the other thread is in operation, even if no events in that thread are active.
>
> Just to be clear, the two cases are:
>
> Case 1
> A single event base is created, and a single event loop is running. Two file descriptors are being monitored by separate events - when one file descriptor has data, that event is "activated" to handle the data. Data is only arriving at one file descriptor, so the other one is "quiet".
>
> Case 2
> Two event bases are created, each being looped by an independent thread. Each base is monitoring a different file descriptor. Only one file descriptor (for the same base as above) is receiving data - the other base/thread is blocked in select. We see a measurable increase in the time it takes for the "active" event to be serviced when compared to Case 1 - the difference is roughly 20%.
>
> Is this cross-interaction expected? Any suggestions on how we might better separate the two channels?

Mysterious!

It's sure not expected that there would be that much of a drop-off.
I'd try to look harder to diagnose what's going on.  Stuff to look at
would include:

 * What OS is this?  You mentioned "select" which makes me think
Windows, but you didn't actually say.
 * Can you trace system calls in the thread that is supposed to be
idle?  Have you verified that it's really sleeping on select, or is
that an inference?  (It's a reasonable inference, mind you, but when
debugging, we shouldn't trust any inferences without checking.)
 * Can you profile the code, and find out which piece exactly is
taking longer here?

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.