This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 18189596ad4c8da26e8cff3648effafdad27dcac (commit) from 19a570c45c61687dd8d1655e2b1118a9cfa54d77 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 18189596ad4c8da26e8cff3648effafdad27dcac Author: Dries Kimpe <[email protected]> Date: Fri Mar 16 14:29:09 2012 -0500 Finished evaluation fixes ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 8e332eb..ab45784 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -208,8 +208,8 @@ amount of paged-in memory used by the executable. In Figure~\ref{fig:writemem} we see that the thread-pool server manages to limit the memory usage even though the client work load increases. This result can be -explained by the design of the thread-pool, which by limiting the number of -active threads used to service client connections also limits the number of +explained by the design of the thread-pool; by limiting the number of +active threads used to service client connections, it also limits the number of concurrent requests. For the other server implementations, memory usage increases accordingly as the number of concurrent requests increases. Although the \aesop server cannot match the thread-pool @@ -235,7 +235,7 @@ shown. \begin{table}[b] \small \begin{center} -\caption{Complexity analysis for example servers} +\caption{Code complexity analysis} \begin{tabular}{lrrr} \hline & CC & mod. CC & SLOC \\ @@ -276,7 +276,7 @@ create and join threads. The thread pool and event model implementation are both much more complex than the thread or \aesop model. An additional complexity of the event model -that +which is not captured by these metrics is that control flow is not preserved across the processing of a given request. For example, servicing a write operation requires five disconnected event handlers. @@ -311,7 +311,7 @@ handle multiple connections concurrently. \end{comment} The example server used for evaluation is simple and differs from real-world -code by the absence of error handling and time-out handling. As shown in Section~\ref{sec:example}, \aesop provides powerful +code by the absence of error handling and time-out handling. As described in Section~\ref{sec:example}, \aesop provides powerful primitives to simplify these activities. The same cannot be said of the event or threaded models, since neither model offers any help in cancelling an outstanding operation. hooks/post-receive -- Triton-private Repository