On Thu, May 13, 2010 at 3:59 AM, <nigelsande...@btconnect.com> wrote:
> This should be a reply to Daniel Ruoso's post above, but I cannot persuade > my nntp reader > to reply to a post made before I subscribed here. Sorry > > And at the core of that, is the need for preemptive (kernel) threading and > shared memory. > > These can (and should!) be hidden from the application programmer, through > the use of language and/or library > level abstractions, of which there are many promising [sic] candidates. > > But fundamentally, they all require that: > > 1) Preemptive scheduling be utilised. > 2) The core interpreter be fully reentrant. > 3) The core runtime libraries be fully reentrant. > 4) That the language distinguishes between, and handles > appropriately, > - process-global entites: IO handles; environment; pwd etc. > - runtime stack-based(*) (lexical) entities: locals (my vars > in perl's terms). > I agree with this more than anything Daniel proposed. I prefer Perl 6 providing a thin interface to a kernel thread (i.e. NPTL), a means of creating shared memory objects between processes and threads, maintain reentrancy as per Buk's summary, and leave the rest for non-core modules. This allows for different threading, event, and shared memory models to emerge. You could then have different models, such as one that emulates Java's abandoned green thread model, something similar to POE, or something that emulates Erlangs process management. If you keep Buk's bullet points and give me a minimalistic interface to threads/shared memory, then it would allow me to create whatever wacky threading/shared memory model I can imagine. I think that's better than doing something that sounds dangerously similar to Java's RMI. -Jason "s1n" Switzer
