Jonathan S. Shapiro wrote: > On Wed, Feb 4, 2009 at 7:31 PM, Sam Rushing > <[email protected] > <mailto:[email protected]>> wrote: > > > > Things I'd like to have in both languages: > > > > ...continuations... > > First, let me say that I don't think you want continuations in their > general form. There is no use-case for re-entrant continuations. > Evidence collected from Scheme programs shows that >99% of all > continuations are used at most once and (if called) are invoked before > their defining scope exits. Basically, continuations are being used as > an exception handling mechanism. The problem with re-callable > continuations is that they create a huge number of semantic > complications and they essentially render the behavior of the program > un-analyzable. Finally, they break the C stack utterly, and the C > stack isn't going away anytime soon. We rejected them in BitC for all > of these reasons, the absence of any use-case being the most > compelling. > Ok, I agree with that, I probably should have been more specific. The idea of having restartable exceptions is appealing to me (maybe because it reminds me of the debugger on the lisp machine), but it's not a show stopper. What I really want are coroutines and generators - i.e., one-shot continuations. Since I'm using CPS, I get all of these for free. It's more likely that I would support full continuations in the high-level (i.e., dynamically typed / 'scripting') language, and not in the low-level one.
> >From personal experience, the only interesting use of real > continuations that I can remember was interrupt dispatch in MacScheme, > and having done my time building microkernels I think that wasn't a > good idea. > > On to threads. > > If you have threads then you have stacks. Each thread will need a > stack and a heap. While it is possible to allocate the stack out of > the heap, the performance of this is problematic. > I'm using heap-allocated continuations - i.e., heap allocated environments and closures. For this particular application (100,000 threads), separate stacks are out of the question. > If you choose to generate C code, you are either going to use the C > stack at procedure calls or you are going to hand-implement procedure > calls on some other stack. The latter is *far* more expensive than > using the C stack. > I agree that it's likely to be more expensive. But the scalability requirements are tough. Another approach I've used is to stack copying - when a thread suspends, its stack is evacuated to the heap. This works amazingly well, and also plays along well with other, oblivious C code - but it's ... offensive. 8^) I want to try an experiment to see if the more 'elegant' approach will perform well. (Appel once argued for heap-allocated frames, but either he's given up or moved on, judging from his "Modern Compiler Implementation..." series). > So I am missing something. I don't see a performance-motivated > argument for avoiding the C stack. The only argument I see concerns > continuations, and continuations raise a whole bunch of concerns and > problems. > > Can you explain a bit more the problem you anticipate with the C stack? As an example, let's say I want to have some kind of network server that can simultaneously handle 20,000 client connections. This is not an unreasonable request, but is amazingly difficult using stock systems. FreeBSD's kqueue() makes this possible, but requires event-driven programming. With the right language (and a scheduler) you can build a non-preemptive thread system that mortals can actually program. Now, my secret preference would be for an operating system that didn't force me to squeeze through expensive system calls and crummy API's like select() in order to do networking, but that's a whole other subject. 8^) -Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
