Welcome to the first post of this series which also just happens to the first design tradeoff I encountered in this project: whether to achieve concurrency by the use of threads, or use the event loop.
Threads sounded appealing at first mainly because I'm familiar with them because of mainstream usage of the term but they came with heavy drawbacks such as, race conditions and then having to manage those conflicts through the usage of lock systems. Another significant drawback is that if we rely solely on threads for achieving concurrency we'll only ever be able to handle a linearly increasing number of clients that scales with the number of available threads.
Event loop was a new topic to me but it offered a single threaded way to tackle these issues. The event loop works with the realization that the main cause for delay in a serialized workflow is the active communication channel waiting for I/O from the socket buffer, once we realize that, we can tackle this by using something call non-blocking I/O.
In non-blocking I/O we poll the socket's file descriptor at every iteration on whether it is ready to read/write or drop the connection.
This ensures we never on a socket if it is not ready for I/O allowing us to handle multiple connections at once, at every turn when a read/write is performed we can then check if the data in the socket's (program maintained) buffer is enough to form a full request or response.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (0)