event-driven system

An Architecture for Highly Concurrent Well-Conditioned Internet Services.pdf

SEDA 项目的相关论文

Page26
The use of helper processes in Flash and Harvest underscores the occasional need for an event-driven system to resort to blocking operations, either to reduce complexity or to make use of legacy interfaces and libraries.
Most event-driven systems develop ad hoc mechanisms for integrating blocking code into the service, requiring careful management of thread/process resources to perform the dispatch.

Page27
An important limitation of this model is that it requires event-handling code to be short and run to completion, to avoid stalling the event-processing threads, and to ensure fairness across a large number of requests.
Flash, Harvest, and other systems address this challenge using separate threads or processes to perform long-running operations asynchronously.

Page29
One of the starting points of the SEDA design was the I/O core framework [54] used by the Ninja system at UC Berkeley.

In the Ninja I/O core, a limited number of threads is used to process requests flowing through the system, and blocking socket and disk I/O operations are converted into asynchronous, split-phase operations using a dedicated pool of threads, similar to the Flash use of helper processes.

Page36
The approach taken in SEDA can be thought of as a middleware layer between the application and the operating system, monitoring application behavior and effecting control over resource consumption.

Page52
First, the use of threads relaxes the constraint that all event-processing code be non-blocking, allowing an event handler to block or be preempted if necessary. In a traditional event-driven system, all blocking operations must explicitly capture the state of the computation and restore it when the operation completes. In SEDA, threads act as implicit continuations, automatically capturing the execution state across blocking operations.

Page54
A SEDA application is constructed as a network of stages, connected by event queues.

A rejected enqueue operation is signaled immediately to the originating stage, for example, by returning an error code. Enqueue rejection acts as an explicit overload signal to applications and should be used by the service to adapt behavior in some way.

Page56
Stages are therefore composed using a protocol, rather than merely type-matching of function arguments and return values, admitting a flexible range of composition policies.

Page61
In Apache, the request queue is implemented using the accept() system call; as discussed previously, this can lead to dropped TCP connections if the listen queue fills up.

A Design Framework and a Salable Storage Platform to Simplify Internet Service Construction.pdf

Ninja 项目的相关论文

Page35
In particular, the programmer doesn't worry about scheduling, as the thread scheduler handles this, or per-task state management, as the compiler transparently places task state on thread stacks in the form of automatic variables.

Programmers are comfortable coding in the sequential programming style of threads, and programmer tools (such as debuggers and thread-safe class libraries ) are relatively mature.

Page39

Unlike a threaded server, with an event-driven system, the programmer must explicitly manage all tasks' state. Partial state associated with a task must be bundled into a self-contained object, and stored in a table indexed by a unique identifier associated with the task. When the program thread pulls an event off of the queue, it associates the event with its task, retrieves this task's state, and invokes the correct task stage with the event and task state as arguments.

Page42
An opportunity that the explicit event queue enables is the ability for the system to perform admission control. If the system is saturated, the event queue will begin to grow, increasing task latency. The system can shed load and reduce latency by simply dropping tasks from this queue, optionally sending error messages back to the sender. Queues in an event-driven system are thus a useful mechanism which exposes resources and the ability to impose resource management policies to the programmer and program.

Page42
We belive that the design space for concurrent servers is not limited to just threaded and event-driven systems, but rather that there is a spectrum between these extremes, and it is possible to build hybrid systems that can exploit the advantages of both programming models. For example, a hybrid system can expose a threaded programming style to programmers, while simultaneously exposing an event queue, and limiting the number of concurrently executing threads so as to prevent performance degradation.

Page49
The wrap pattern placas a queue in front of a stage, and assigns a bounded number of threads to the stage in order to process tasks that arrive on its queue.
The queue serves to condition the stage to load; excess work that cannot be absorbed by the stage's threads is buffered in the queue, increasing latency through the stage.

Page61
This queue/thread combination is the result of applying the "wrap" pattern with a minimally sized thread pool.

Page156
A known weakness of event-driven models is the increased difficulty of debugging them. The control flow of a task in an event-driven model is no longer equivalent to the control flow of a single thread, since tasks can span threads by crossing thread boundaries, or they can have no execution context at all while sitting idle in queues.

Traditional debuggers only allow programmers to inspect variable state and to trace the execution of threads; such debuggers have no notion of causality from events, and accordingly it is impossible for them to provide an event tracing facility.