What logically is an event loop in a thread?

Question

I came across node.js and python's tornado vs the Apache.

They say :

• Apache makes a thread for every connection.
• Node.js & tornado actually does event looping on a thread and a single thread can handle many connections.

I don't understand that what logically be a child of a thread. In computer science terms:

• Processes have isolated memory and share CPU with context switches.
• Threads divides a process.
• Therefore, a process with multiple control points is achieved by multiple threads.

Now,

What how does event loop works under a thread ?

How can it handle different connection under 1 control of a thread ?

Update :

I mean if there is communication with 3 sockets under 1 thread, how can 1 thread communicate with 3 sockets without keeping anyone on wait ?

Answer 1

An event loop at its basic level is something like:

while getNextEvent (&event) {
    dispatchEvent (&event);
}

In other words, it's nothing more than a loop which continuously retrieves events from a queue of some description, then dispatches the event to an event handling procedure.

It's likely you know that already but I'm just explaining it for context.

In terms of how the different servers handle it, it appears that every new connection being made in Apache has a thread created for it, and that thread is responsible for that connection and nothing else.

For the other two, it's likely that there are a "set" number of threads running (though this may actually vary based on load) and a connection is handed off to one of those threads. That means any one thread may be handling multiple connections at any point in time.

So the event in that case would have to include some details as to what connection it applies to, so the thread can keep the different connections isolated from each other.

There are no doubt pros and cons to both options. A one-connection-per-thread optio n would have simplified code in the thread function since it didn't have to deal with multiple connections but it may end up with a lot of resource usage as the load got high.

In a multiple-connection-per-thread scenario, the code is a little more complex but you can generally minimise thread creation and destruction overhead by simply having the maximum number of threads running all the time. Outside of high-load periods, they'll just be sitting around doing nothing, waiting on a connection event to be given to them.

And, even under high load, it may be that each thread can quite easily process five concurrent connections without dropping behind which would mean the one-connection-per-thread option was a little wasteful.

---

Based on your update:

I mean if there is communication with 3 sockets under 1 thread, how can 1 thread communicate with 3 sockets without keeping anyone on wait ?

There are a great many ways to do this. For a start, it would generally all be abstracted behind the getNextEvent() call, which would probably be responsible for handling all connections and farming them out to the correct threads.

At the lowest levels, this could be done with something like a select call, a function that awaits activity on one of many file descriptors, and returns information relating to which file descriptor has something to say.

For example, you provide a file descriptor set of all currently open sockets and pass that to select. It will then give you back a modified set, containing only those that are of interest to you (such as ready-to-read-from).

You can then query that set and dispatch events to the corresponding thread.