The server ideally will accept requests, return quickly, and then do work. To do so requires some sort of threading... but of course it's hard to guarantee all tasks may be threaded. I propose a three-mode model:

• blocking - Each app runs on main thread preventing return of current request and handling of new requests
• threaded - Only one app may execute on one execution thread at a time. All other apps block until the current app is done. This could be implemented with a queue so that a request may return and the app will wait it's turn to produce results.
• multi-threaded - Each app runs on it's own thread.

blocking

No attention to threading required.

threaded

Threading requires each app is self-contained: all objects used by the app are it's own (queue, tasks, dependencies, etc). This is almost the case, although there are some outlying (bugs)[http://bahuvrihi.lighthouseapp.c...].

Threading is less save than blocking but should not be dangerous provided no apps run off-queue. Effectively there are only two threads:

• The server thread which utilizes env, interacts with the user, but does not work with apps or tasks (this could be an issue with globals).
• The application thread which runs apps, but does not interact with the user or utilize env.

multithreaded

Multithreading also requires each app is self-contained.