Jason Switzer wrote:
On Thu, May 13, 2010 at 3:59 AM, <nigelsande...@btconnect.com> wrote:
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.
The support of threading should be completely optional. The threading
support should not be active by default.
See also http://www.ibm.com/developerworks/linux/library/l-posix1.html
and fathom why "Threads are fun" reads to me like how a drug dealer
lures you to at least try it once.
Rather fork-join!
(Do Perl_6 hyper-operators need pthreads?)
--
Ruud
