[pypy-dev] Thinking about the GIL

[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: 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

Cheers,
Ben

> 
> 
> --
> Regards,
> Benjamin
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev