I'll try to reply as good as possible, but I'm sure others will do better.

David Brunton wrote:
> This last SOTO re-reminded me of what an inveterate fan I am of Perl 6.  Wow.
> My question today is about concurrency.  I can imagine how things like IPC 
> Mailboxes 
> (e.g. RFC 86) happen in modules.  I can also imagine why Threads (e.g. RFC 1) 
> should 
> be in modules- given the obvious dependence on underlying OS.
> I do see both C<fork> and C<wait> in S29, but not in STD.pm, which brings me 
> to
the questions:

There's no need for any "keyword" to be in STD.pm. STD.pm just defines
the grammar. Syntactically fork will be like just another sub, so it can
safely be handled in the compiler's runtime.

> * Where will C<fork>, C<wait>, and possible friends (e.g. Perl 5's 
> C<open>-with-|) live?

What do you mean by "where"? The namespace? Or the implementation?

> * Is there any expectation of message-passing concurrency functions living 
> inside STD.pm?

Again it won't be in STD.pm, because it doesn't care about it.
But I think there will be both event based and thread based concurrency
in Perl 6.
Larry Wall usually points to this paper:

Something like that, with a perlish interface, will be part of Perl 6's
concurrency model.

> * How about shared/software-transactional memory?

Maybe http://svn.pugscode.org/pugs/docs/Perl6/Spec/Concurrency.pod
(still a draft) contains a bit more helpful information.

> Hopefully I'm not inadvertently starting any kind of flame-fest
> about anyone's favorite concurrency model here :-D

Why flame, when we can have all of them at once? ;-)

Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to