Feature request: ability to use libeio with multiple event loops

Hongli Lai hongli at phusion.nl
Thu Dec 22 08:05:08 CET 2011

On Thu, Dec 22, 2011 at 3:02 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> With threads, you can avoid swapping some registers, most notably the MMU
> registers, which are often very costly to swap, to the extent that a number
> of cpus even have extra support for multiple "contexts".
>> Are you talking about hardware simultaneous multithreading
>> (http://en.wikipedia.org/wiki/Simultaneous_multithreading), e.g.
>> HyperThreading?
> No, just distant history, try
> http://en.wikipedia.org/wiki/Thread_%28computer_science%29 if you like
> wikipedia:

According to that same Wikipedia article, some CPUs have multiple
register files in order to reduce thread switching time, i.e. what you
describe as extra support for multiple contexts. According to the
article, that idea came in the late 1990s to x86 desktop CPUs when
Intel introduced HyperThreading. So it looks like we're talking about
the same thing.

>> Let me get this right before continuing the discussion. Are you saying
>> that this program (in pseudo code):
> Thats not all I am saying, but I would say that for these programs, yes.

I agree that threads tend to be overhyped compared to processes, but
I'm here to learn the truth, which is why I'm asking these things.

It's true that the second program adds an extra layer of indirection
(the 'data' variable). However:
1. If the data is accessed frequently then both the pointer and the
ThreadData that it points to should be cached by the CPU cache, making
the indirection very cheap.
2. Suppose the system has two cores and N = 4, so two processes or two
threads will be scheduled on a single core. A context switch to
another thread on the same core should be cheaper because 1) the MMU
register does not have to swapped and 2) no existing TLB entries have
to be invalidated.

I think that (1) and (2) are sufficiently beneficial that the program
should run faster overall, even with the extra indirection. Do you not
think so?

Phusion | Ruby & Rails deployment, scaling and tuning solutions

Web: http://www.phusion.nl/
E-mail: info at phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

More information about the libev mailing list