...

[helm.git] / helm / papers / calculemus-2003 / hbugs-calculemus-2003.tex

diff --git a/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex b/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
index 49322ba2e7f0eebc3e15cd01a5f8e897f5c19b20..b6425289fab3b9fce7c0a0da5115e44ef13985c7 100644 (file)
--- a/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
+++ b/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
@@ -154,9 +154,6 @@
     parameters. More structured hints can also be used: an hint can be
     as complex as a whole proof-plan.
 
-    \myincludegraphics{interfaces}{t}{10cm}{\hbugs{} \wss{} interfaces}{\hbugs{}
-    \wss{} interfaces}
-
     Using W3C's terminology \cite{ws-glossary}, clients act both as \ws{}
     providers and requesters, see Fig. \ref{interfaces}.
     They act as providers for the broker (to receive hints)
@@ -172,6 +169,9 @@
     possibile posto dove mettere una mini-sessione interattiva. L'appendice
     un altro.}
 
+    \myincludegraphics{interfaces}{t!}{10cm}{\hbugs{} \wss{} interfaces}
+     {\hbugs{} \wss{} interfaces}
+
     \hbugs{} clients act as MONET clients and ask brokers to provide access to a
     set of services (the tutors). \hbugs{} has no actors corresponding to
     MONET's Broker Locating Service (since the client is supposed to know the
@@ -424,18 +424,19 @@ the \hbugs{} architecture.
 
     Our current implementation is based on a multi threaded architecture
     exploiting the capabilities of the O'HTTP library. Each tutor is composed
-    by two thread always running plus
+    by one thread always running plus
     an additional thread for each running \musing{}. One thread is devoted to
     listening for incoming \ws{} request; upon correct receiving requests it
-    pass the control to the second always-running thread which handle the pool
-    of running \musings{}. When a new \musing{} is requested, a new thread is
-    spawned to work them out; when a request to interrupt an old \musing{} is
-    received, the thread actually running them is killed freeing its
-    resources.\ednote{CSC: A cosa dobbiamo questa architettura delirante? Se non
-    ricordo male al problema dell'uccisione dei thread. Ora o si spiega
-    il motivo di questa architettura o si glissa/bluffa. Zack: cosa ti sembra
-    delirante? che i thread vengono uccisi? ... non mi e' molto chiaro ...
-    CSC: la motivazione per avere due thread always running e non due}
+    pass the control to a second thread, created on the fly, to handle the
+    incoming request following the classical one-thread-per-request approach in
+    web servers design.
+    If the received request is \texttt{Start\_musing}, a new thread is
+    spawned to handle it and the thread in duty to handle the HTTP request
+    returns an HTTP response containing an identifier of the just started
+    musing. Otherwise, if the received request is \texttt{Stop\_musing},
+    it carries a \texttt{musing} identifier used to identify the thread
+    responsible for a \texttt{musing}; that thread gets killed and an HTTP
+    response is returned.
 
     This architecture turns out to be scalable and allows the running threads
     to share the cache of loaded (and type-checked) theorems.