Multithreading #21

New Issue

Jef Roosens · 2023-11-16T18:25:48+01:00

Jef Roosens commented

2023-11-16 18:25:48 +01:00

There's no real reason we couldn't run multiple threads with each thread having its own event loop managing connections. I'm not sure if this would actually improve performance, but there's only one way to find out of course.

The only real blocker for this right now I think would be #20.

There's no real reason we couldn't run multiple threads with each thread having its own event loop managing connections. I'm not sure if this would actually improve performance, but there's only one way to find out of course. The only real blocker for this right now I think would be #20.

Jef Roosens added the

Kind/Enhancement

label 2023-11-16 18:25:48 +01:00

Jef Roosens commented

2023-12-03 13:29:53 +01:00

Poster

I've got a possible design for this:

Each worker thread runs the event loop with its own set of connections n everything
one of these threads is the main thread that also polls the listening socket for incoming connections, and places them in a thread-safe queue
each event loop receives its new connections from this queue (using non-blocking locking)

important here is that we don't want to simply run a single request per thread, the goal is to scale the event loop efficiency to multiple threads/cores, allowing us to process multiple event loops in parallel

i'm not sure how well this simple idea will distribute requests among the event loops, but we can measure that first and see whether a more sophisticated approach is needed.

I've got a possible design for this: Each worker thread runs the event loop with its own set of connections n everything one of these threads is the main thread that also polls the listening socket for incoming connections, and places them in a thread-safe queue each event loop receives its new connections from this queue (using non-blocking locking) important here is that we don't want to simply run a single request per thread, the goal is to scale the event loop efficiency to multiple threads/cores, allowing us to process multiple event loops in parallel i'm not sure how well this simple idea will distribute requests among the event loops, but we can measure that first and see whether a more sophisticated approach is needed.

Jef Roosens commented

2023-12-13 10:20:54 +01:00

Poster

Along with switching to epoll, the dev branch now also supports running the event loop on multiple threads, with the orchestration being done with epoll and oneshot file descriptor events. However, the LSM store isn't safe yet for concurrent use, so for now we will leave the amount of threads to 1.

I will close this issue because the LNM loop now does indeed support multithreading, but Lander itself won't be multithreaded just yet.

Along with switching to `epoll`, the `dev` branch now also supports running the event loop on multiple threads, with the orchestration being done with `epoll` and oneshot file descriptor events. However, the LSM store isn't safe yet for concurrent use, so for now we will leave the amount of threads to 1. I will close this issue because the LNM loop now does indeed support multithreading, but Lander itself won't be multithreaded just yet.

Jef Roosens closed this issue

2023-12-13 10:20:54 +01:00

Sign in to join this conversation.