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.