On Sat, 2006-12-02 at 19:21 +0000, Sam Mason wrote: > On Sat, Dec 02, 2006 at 12:34:54PM -0500, Jonathan S. Shapiro wrote: > > Portions of the activation handler clearly need to be in assembler > > because they deal with register-level interactions. > > Indeed they will. The aim of pointing out coroutines was that it struck > me as a nice conceptual model that the user land scheduler could use > internally. I've just realised that this message should really have > gone to the Coyotos list instead of this one! Ah well, seemed like a > langauge thing at the time.
No, I think this is the right list. The coroutine concept has utility independent of the Coyotos activation issues. > I agree that BitC's core should be as small as possible. It's going to > be difficult enough as it is! Swaroop now has the core semantics documented, with one trivial exception that I recognized today (but it's no big deal). I don't know if he has published that as a TR yet. If not, I'll kick his butt appropriately tomorrow. Swaroop: you've been warned! :-) > > I'm not convinced that the language should provide > > support for threading or co-routines. Speaking from my perspective as a > > programmer, most language support for these features is badly flawed. > > There never seems to be enough thought put into the design of these > things... It is always tempting to say that, but I think this is not the real culprit. I think the real issue is that concurrency is a lot harder than we want to believe, even in its simplest forms. For example: co-routines generally turn into event dispatch, and there is often some non-determinism about what co-routine runs next. This introduces a *huge* problem for program analysis. shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
