[pypy-dev] Thinking about the GIL

Leonardo Santagada santagada at gmail.com
Tue Mar 15 18:25:23 CET 2011


On Tue, Mar 15, 2011 at 11:36 AM,  <Ben.Young at sungard.com> wrote:
>
>
>> -----Original Message-----
>> From: pypy-dev-bounces at codespeak.net [mailto:pypy-dev-
>> bounces at codespeak.net] On Behalf Of Benjamin Peterson
>> Sent: 15 March 2011 14:18
>> To: Young, Ben
>> Cc: pypy-dev at codespeak.net
>> Subject: Re: [pypy-dev] Thinking about the GIL
>>
>> 2011/3/15  <Ben.Young at sungard.com>:
>> >
>> >
>> >> -----Original Message-----
>> >> From: pypy-dev-bounces at codespeak.net [mailto:pypy-dev-
>> >> bounces at codespeak.net] On Behalf Of Benjamin Peterson
>> >> Sent: 14 March 2011 19:29
>> >> To: Timothy Baldridge
>> >> Cc: PyPy Dev
>> >> Subject: Re: [pypy-dev] Thinking about the GIL
>> >>
>> >> 2011/3/14 Timothy Baldridge <tbaldridge at gmail.com>:
>> >> > They may not be thread-safe, but as far as a program goes, do we
>> >> > really care? If I have two threads adding items to the same list,
>> >> > should I really be expecting the interpreter to keep things
>> > straight?
>> >> > What's wrong with forcing the user to lock structures before
>> editing
>> >> > them? This is something that Java, and C#, and C++ all require.
>> >>
>> >> Yes, the Python interpreter should never crash because of user
>> >> mistakes.
>> >>
>> >
>> > C# structures aren't thread-safe, but you can't crash the CLR by
>> using
>> > them in a multithreaded manner
>>
>> The primitive data structures must be thread-safe, though.
>>
>
> No, just cleverly designed with the memory model in mind I believe (at
> least there's no locking or even atomic synchronisation), and you can
> get errors, it just wont bring down the VM

That is what I think he meant. The only way that I know for a vm to be
thread-safe is its internal structures to be thread-safe. The exposed
C# structures might not be, but the VM ones have to.

-- 
Leonardo Santagada



More information about the Pypy-dev mailing list