On Tue, Mar 15, 2011 at 11:36 AM, <ben.yo...@sungard.com> wrote: > > >> -----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
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 _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
