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 <aurelien.campeas@logilab.fr> Subject: Re: [pypy-dev] Thread cloning (coroutine cloning, really) To: Armin Rigo <arigo@tunes.org> Cc: pypy-dev@codespeak.net Message-ID: <20060512104217.GB28391@crater.logilab.fr> 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

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 <aurelien.campeas@logilab.fr> Subject: Re: [pypy-dev] Thread cloning (coroutine cloning, really) To: Armin Rigo <arigo@tunes.org> Cc: pypy-dev@codespeak.net Message-ID: <20060512104217.GB28391@crater.logilab.fr> 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