> -----Original Message----- > From: pypy-dev-boun...@codespeak.net [mailto:pypy-dev- > boun...@codespeak.net] On Behalf Of Benjamin Peterson > Sent: 15 March 2011 14:18 > To: Young, Ben > Cc: pypy-dev@codespeak.net > Subject: Re: [pypy-dev] Thinking about the GIL > > 2011/3/15 <ben.yo...@sungard.com>: > > > > > >> -----Original Message----- > >> From: pypy-dev-boun...@codespeak.net [mailto:pypy-dev- > >> boun...@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 <tbaldri...@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@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
