To do this sort of thing in one process, as a general rule, you have to avoid operations which block or more generally, which take a long time.

This means doing things like using async I/O, breaking long computations into chunks which can be called on a 'tick' basis etc.

This can be a pain (as can servicing more than one event loop in a program). It is a different kind of pain than threading or fork+IPC.

A 'normal' sequential program is essentially a list of "do A, do B, do C". It doesn't matter if doB takes a long time, you've got nothing else to do apart from doB anyway (since you don't have to doC until doB is done).

The problem comes when your program wants to respond to things (user input, network connections etc). Because now it has (at least) two jobs to do concurrently - "listen for new events" and "handle event".

You can then:

1. Run a new sequential program to handle each task.

   This is both the thread model and the fork model. Both of these provide a new 'context of execution' which can then sit doing its own doA, doB, doC. Forking and threading only differ in what is shared between the two contexts (see "man clone" on a Linux box for a nice list of the sorts of things which might or might not be shared between two contexts of execution, classical processes and threads aren't the only options).

2. Write in a different style. This is the event loop approach, where no operation is allowed to take a long time because you have to get back to service the event loop. (How long? Depends on how long you mind waiting for an event to be handled). You can break up a long operation by saving enough context for you to respond to the event you know it will generate in the future. (e.g. for an async read of a file into a buffer, your context will need to include the buffer and current position).

   Objects are great for encapsulating such context. As are closures.

   Your example shows another complication in event-based code, where you have more than one event system. In this case, you need one event loop to be the 'master' and a hook to the other to 'handle one event'. If you don't have that then you can't use this approach.