Re: call/cc

["S. Alexander Jacobson" <address@hidden>]

Ok, but multithreaded servers are relatively easy to understand.
Passing contuations around seems harder.  (I've done the former but not
the later).

Why not leave the non-contination code alone instead modify server's OS
threads to be non-premptive*?  Or allow the language/runtime to specify
a threading model?  The original unix Java implementations used a
non-preemptive threading implementation.  If any of that code is still
around, then it wouldn't be that hard to give users a choice.


-Alex-

* Yes, some code that relied on preemptive multitasking would break, but I
think that would be visible and fixible pretty rapidly.

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-917-783-0889 voice                    1-212-697-1427 fax


On Tue, 11 Dec 2001, Tony Kimball wrote:

>
> Here's the single most practical reason why I love call/cc: Web
> application servers et filia.
>
> - NThreads > CPUParallelism is a bad condition for high performance IO
>   systems.  Examples abound in which naively implemented fully
>   asynchronous I/O engines beat the pants off of highly tuned
>   multithreaded servers, up to the limit of 1 CPU.
>
> - Introducting threads is an engineering/business error, in an
>   environment with a single physical resource.  It introduces a
>   raft of maintenance problems, particularly in the presence of
>   maintainer-churn, from non-determinism to synchronization
>
> - It is a nightmare of complexity to implement generator and sink
>   modules for any fully asynchronous single-threaded I/O engine.  Try
>   to integrate PHP into mathopd, for example, and weep.
>