Re: call/cc

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

On Wed, 12 Dec 2001, Tony Kimball wrote:
> : 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.
>
> Non-premptive threading is either explictly scheduling or implicitly
> scheduling.  In the explicitly scheduling case, you've got all the
> code impact of a call/cc-based design, with none of the advantages.
> In the implicitly scheduling case, you've got a severe performance
> problem, in the form of an essentially uncontrollable latency -- no
> approach to even soft real-time guarantees is possible, a priori.

I don't think it is such a big issue in practice unless request sizes vary
enourmously and your CPU is really slow.

If you have a non-preemptive thread implementation, the web server serves
as much of each request as it can until I/O gets blocked (either waiting
for a database call or waiting to write back to the client), and moves on
to another.

If your really concerned that a thread is not getting enough attention,
you can have your dispatcher thread yield() until the older thread gets
processed.

I think we are falling away from the list charter here.

My only point is that there are other ways to get the same advantage
without the cost in code readability (requiring the programmer to learn
yet another technique).

That being said, if the common server idiom was asynch rather than thread
dispatch, people would get used to that instead.

-Alex-

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