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 db6ec9a44f89d90c79084fa36c4c74dde923efaf (commit) from 9b070a9efc8a20f089817238aba5042d9a518059 (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 db6ec9a44f89d90c79084fa36c4c74dde923efaf Author: Phil Carns <[email protected]> Date: Thu Mar 15 23:10:15 2012 -0500 shorten description of server implementations ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 23 ++++++++--------------- 1 files changed, 8 insertions(+), 15 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 3851a1b..b9803b4 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -101,27 +101,23 @@ pool with 4 threads. The thread-per-client server spawns a dedicated thread for each client connection. All requests for a given client are handled within the same thread. This model -uses synchronous socket operations and synchronous file read and write operations. -When the client disconnects, its associated thread is destroyed. +uses synchronous socket and file I/O functions. \paragraph*{Thread-per-client-nb} The thread-per-client-nb server is identical to the thread-per-client server except that it uses asynchronous socket calls in place of synchronous -socket calls. For example, in order to send a message, a thread will -perform asynchronous sends until it encounters the \code{EWOULDBLOCK} error code. -It then polls the socket until it is ready and continues sending data. -We implemented this version to investigate the possible performance difference -between the synchronous and asynchronous socket calls when -all other factors remain equal. +socket calls and uses \code{poll()} to determine when a socket can make +progress. +We implemented this version to isolate the performance difference resulting +from asynchronous socket access when all other factors remain equal. \paragraph*{Thread-per-operation} The thread-per-operation server uses an event loop to watch all client connections for activity. When a new request is available, a thread is -spawned, and the request is handled completely from within that thread. When -the request is complete, the thread is destroyed. Synchronous socket operations -and standard file read and write functions are used in this implementation. +spawned, and the request is handled completely from within that thread. +This implementation uses synchronous socket and file I/O functions. \paragraph*{Thread-pool} @@ -129,10 +125,7 @@ The thread-pool server is similar to the thread-per-operation server in that it uses an event loop to watch connected client connections for activity. However, instead of creating a new thread to service each active client, the connection is added to a queue. A fixed-size thread pool is used to service -the connections from the queue. The thread pool was implemented following -best practices for scalable condition-variable performance as described in -\cite{hp-cond-variable}. - +the connections from the queue. \paragraph*{Event} hooks/post-receive -- Triton-private Repository