I'm not sure there is an issue -- I'm just wondering...for example: Is [CHL]OLA's binding mechanism designed to be free of races, say in the event that multiple threads message a single object asychronously?
Are the default GC options multi-threaded, or at least threads-aware/thread-safe? Yes, once can certainly create & destroy threads via C -- my question goes more to the heart of whether the object lambda architecture itself is built "threads ready" or whether that is presently beyond scope. As for syntax issues, Smalltalk, operator precedence, etc., I seem to have inadvertently contributed to a discussion thread which seems to miss the point... Part of what I see as so exciting about [CHL]OLA is the ability to support multiple syntaxes on top of a common object-lambda architecture (with a single baseline semantic). One doesn't have to choose either Smalltalk or C-like operator precedence. Instead, you simply build and work in the language or dialect best suited for your particular application (math, systems programming, object modeling, etc.), without sacrificing performance or runtime interoperability. In complaining about Squeak, it's wasn't so much Smalltalk's particular syntax I was objecting to, but rather, the notion of fixed syntax altogether. It's so limiting. -----Original Message----- From: Jason Johnson [mailto:[EMAIL PROTECTED] Sent: Thu 11/22/2007 9:49 AM To: Warren DeLano Cc: Waldemar Kornewald; VPRI Fonc Subject: Re: [fonc] productivity On Nov 21, 2007 8:57 PM, Warren DeLano <[EMAIL PROTECTED]> wrote: > Waldemar, > > though I do still have some concerns regarding the potential for native > support of thread-level concurrency (obligatory nowadays given 4-8+ core > desktops). LOLA can call out to any C library, so you have at least the same threading capabilities as a C program would have. What's the issue?
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
