On Wednesday 24 October 2001 08:28 pm, you wrote: > I’ve just spent some time looking through the various RFC’s for Perl 6. > > IMHO: The various proposals dealing with multi threading, synchronization > and RPC can be solved in a different way. > > Instead of thinking about multiple threads, one could think about multiple > execution contexts. Each instance of an object must belong to one and only > one execution context. Each execution context has an attached security > context and a security manager. > > When making a call from an object in one execution context to a method of > an object in another execution context the security context of the caller > is passed to the receiver an validated by it’s security manager before > being allowed to execute. Asynchronous execution could be implemented using > “oneway” functions and “future” variables and a combination of both. > “future” variables would allow for returning results from “oneway” > functions, and for turning synchronous functions into “oneway” functions. > > “deferred” methods would also be very nice. A deferred method is something > that would be executed at some later time when the current execution > context is idle. > > If the following keywords were added to Perl: > 1. abandon > 2. asynch[ronous] > 3. at > 4. cancel > 5. deferred > 6. future > 7. oneway
[snip] > > I'm well aware that most of this functionality can be achived by other > means - but I think a language and runtime level solution would be most > elegant and portable. My choice of syntax and keywords are for illustration > purposes only. Well, from the sideline, I have a couple of comments. First, parrot is supposed to be language agnostic, so such an implementation would go unused in python / perl5 lingo. Perhaps there could be support modules bolted on, who knows. However, this sort of RFC is probably a bit too late (ironically) to make any headway, given that we're in the post RFC stage. As for the technical feasibility. I'm not sure what direction you're trying to take. You speak as if this were an alternative to a threading model, but you don't talk about fake threading or even dispatch-driven code (which I'm sure is already ruled out in the interest of main-stream performance). Thus I'm not quite sure what your vision of the implementation is. The pseudo-perl code is really only syntactic sugar. Again, parrot doesn't care what perl6 does. Only what perl6 needs at a fundamental level. If you want to try again in terms of op-codes, then you might make some more head-way. In general, however, IPC is not an issue parrot is concerned with. As far as I understand, it won't even be part of the core, but instead live in dynamically loaded system modules. I believe the real push of threading is less involved with IPC (or ITC as the case may be) but to provide state-of-the-art programming capability in a reliable (and performance minded) manner. Apache 2.0 will be MT, and perl5 is not, thus there's going to be a rift if at least an MT mod_perl can't be relied apon. The MT has to co-exist with c-librarires (a la DBD drivers), and it seems will be very close to a posix varient (with locking on marginally shared structures). I think a litmus test is going to be MT DBD support. (Currently many CPAN modules refuse to compile alongside perl5.005 threads) None the less, separate execution contexts is exactly what seems to be going forward. Each thread will have (at least) one parrot interpreter datastructure. I'm assuming that this implies completely separate name-spaces. So long as there are well thought out interfaces between the threads, any such IPC that you refer to can be imlemented ontop. In fairness though, I've been partial to the QNX real-time-OS, which utilized at it's lowest level a message passing architecture (not too dissimilar in fundamental concept from what you're suggesting). The advantage was that these messages could be relayed/tunneled anywhere (including other processes or other networks networks). But the messages were hidden behind system calls (as with TCP/IP based messenges), so performance wasn't hindered too badly. That said, I'm not seeing an advantage that outweighs the specialization complexity in implementing what I do understand about your RFC. -Michael
