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: http://www.seas.upenn.edu/~lipeng/homepage/unify.html Something like that, with a perlish interface, will be part of Perl 6's concurrency model. > * How about shared/software-transactional memory? Yes. 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 -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
