Faré wrote:
Relevant discussion on the uptick blog: http://wagerlabs.com/uptick/2005/07/very-frustrating-saturday.html The author has rival concerns about speed and memory-efficiency of threads.
My take:
The idea is that there should be a standard API, and then multiple ways of implementing it. Providing a light-weight implementation in terms of green threads (Eric Lavigne just ported erlisp to cmucl), or of a continuation passing transform (Screamer style), are definitely implementation strategies for Erlisp. And if all goes well, we can mix and match implementation strategies within a same Erlisp universe: gimme slower memory-efficient threads for this, faster memory-wasting threads for that, migratable (Tube-like) threads for that other thing, etc.
That has been my take all along! And the code to do this is already there. (That is, there is a PROCESS class with THREADED-PROCESS as a subclass and more subclasses planned.)
Guys like Joel make me wonder if people actually read the Erlisp roadmap [0]. Is it too fluffy? Not clear enough? Too long? Not structured properly? I'm willing to rewrite it if that can prevent things like these...
- Dirk