William Leslie wrote: > (of course, I take it you've read > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html , > every python developer has.) > > It's not obvious to me why storing 100,000 stacks and thread states > even constitutes an alternative to async I/O. > > Heh, you're preaching to the choir here. I've been arguing against SMP for many years. I'm an MIMD guy myself.
You can do some really interesting things with a high-level language and event-driven async stuff. But when you try to plug more than one piece together, you get an explosion of state space. Using coroutines/green-threads/whatever-you-want-to-call-them, you can tame that code and make it look like 'threaded' code. Your complicated state is stored in local variables. (which need not use 64KB or 4MB to store 112 bytes of actual state). An example. Let's say you're writing an HTTP server. You've just accepted a connection from an unknown IP address. Now you need to contact an unknown number of DNS servers via UDP (let's say you have name-based policies). Each one of these network transactions requires state - and of course you have to remember after all the DNS stuff is done to go back to the HTTP request. The only reasonable way to do this in a language without continuations (or coroutines) is to write your code in continuation-passing style. In other words, when you call the dns_resolve_ip() routine, you pass in a success continuation and a failure continuation. Or, you can use a language that can invert all that and make it look like this: conn, addr = http_server.get_connection() name = resolver.get_name (addr) spawn_http_thread (conn, addr) ... [failures are done with exceptions] Kernels are coroutine systems, at heart. They're just not thought of that way. > Regarding simple python bitc prototypes, it could be a bit of fun > writing a translatable bitc machine with pypy- it'd be usable faster. > > Not sure what you mean here. PyPy with BitC as a target? -Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
