On Tue, Mar 15, 2011 at 11:36 AM, <[email protected]> wrote: > > >> -----Original Message----- >> From: [email protected] [mailto:pypy-dev- >> [email protected]] On Behalf Of Benjamin Peterson >> Sent: 15 March 2011 14:18 >> To: Young, Ben >> Cc: [email protected] >> Subject: Re: [pypy-dev] Thinking about the GIL >> >> 2011/3/15 <[email protected]>: >> > >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:pypy-dev- >> >> [email protected]] 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 <[email protected]>: >> >> > 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
