On Wed, May 24, 2006 at 09:06:20AM +0200, Grégoire Dooms wrote: > > >Date: Fri, 12 May 2006 12:42:17 +0200 > >From: Aur?lien Camp?as <[EMAIL PROTECTED]> > >Subject: Re: [pypy-dev] Thread cloning (coroutine cloning, really) > >To: Armin Rigo <[EMAIL PROTECTED]> > >Cc: [email protected] > >Message-ID: <[EMAIL PROTECTED]> > >Content-Type: text/plain; charset=iso-8859-1 > > > <snip> > >We could restrict the programming style for code to be running inside > >comp. spaces but if it is possible to effectively clone everything > >(for some ill-defined notion of everything) then it'l be fine. I'm not > >100% sure. Here are some of the constraints : > > > >In principle, side-effects on the parent space and the outer world > >should be forbidden from within a running comp. space ('cause the jury > >is still out on its outcome). > > > > If I can throw in my two cents, you should really try to remove this > limitation of Mozart. This is a real pain in the ass when you want to > know what happens in a space (I used to need that in Mozart for > debugging or statistics). In Mozart it is possible to use a hack in > order to have side effects out of a space (ie modifiy state outside the > space) by using ports. > I think a design which would allow it would be much more Pythonic (we > are between consenting adults :-)
I had been thinking about that indeed. Glad you tell us what you think. Anyway, by default/as a starting point PyPy's comp spaces will be "open" ; as seen in Mozart with ports or whatever it must be hard to restrict operations enough to ensure a proper sealing of a space and in the case of Python, worse than hard ... > > Best, > -- > Grégoire > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
