On Fri, Oct 4, 2013 at 4:28 AM, Roy Smith <r...@panix.com> wrote: > Well, the GIL certainly eliminates a whole range of problems, but it's > still possible to write code that deadlocks. All that's really needed > is for two threads to try to acquire the same two resources, in > different orders. I'm running the following code right now. It appears > to be doing a pretty good imitation of a deadlock. Any similarity to > current political events is purely intentional.
Right. Sorry, I meant that the GIL protects you from all that happening in the lower level code (even lower than the Senate, here), but yes, you can get deadlocks as soon as you acquire locks. That's nothing to do with threading, you can have the same issues with databases, file systems, or anything else that lets you lock something. It's a LOT easier to deal with deadlocks or data corruption that occurs in pure Python code than in C, since Python has awesome introspection facilities... and you're guaranteed that corrupt data is still valid Python objects. As to your corrupt data example, though, I'd advocate a very simple system of object ownership: as soon as the object has been put on the queue, it's "owned" by the recipient and shouldn't be mutated by anyone else. That kind of system generally isn't hard to maintain. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
