[Python-ideas] Fwd: Concurrent safety?

[Mike Meyer]

On Fri, Nov 4, 2011 at 7:38 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On Fri, Nov 4, 2011 at 5:36 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>> Jim Jewett writes:
>>  > On Thu, Nov 3, 2011 at 12:35 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>
>>  > > As for "wrapped C libraries", I'm having trouble imagining what you're
>>  > > talking about.
>
>>  > C code (currently) can create or modify python objects using a C
>>  > pointer, instead of python access.
>
>> Right, and that means they complete bypass Mike's proposal, too.  So
>> his reference to them was a non sequitur in context, because AFAICS
>> his proposal couldn't do anything more about them than mine could.
>
>> Can it?
>
> Not if it is just an additional compile-time restriction.

Which is why it calls for raising exceptions at run-time.

> If the implementation is prepared to enforce the restriction at
> run-time, that will almost certainly require some changes to memory
> allocation.  If done right, that might also be able to lock out rogue
> C code, which should also allow a tracing GC, stronger security
> guarantees, and GIL removal.

I'm not really interested in locking out rogue C code - or at least
not malicious code. This is very much in the "we're all adults here"
vein, in that if you want to go out of your way to defeat it, it won't
stand in your way.

> I don't personally see it happening without a currently unacceptable
> slowdown for all memory access, but if he is looking 5-10 years out,
> it is plausible.  (I would still bet against it for mainstream
> CPython, but it is plausible.)

I'm just trying to get the ball rolling. It clearly won't be in Python
3, so I'm looking to at least Python 4. What I expect to come out of
this is an information PEP summarizing the discussion, and possibly
some code that might be useful now (i.e. - a new library, or an
automated "concurrency safe" auditor, or ...).

  <mike