3 ms·
Yeah, that’s something, at least. Wouldn’t the order that mutations happen still matter, even though they have to acquire a lock? Not a pythoneer, myself.
by pohl 4y ago
Yeah, that’s something, at least. Wouldn’t the order that mutations happen still matter, even though they have to acquire a lock? Not a pythoneer, myself.
- masklinn 4y agoNot in the context of memory safety. You can still have race conditions up the ass, but not data races, unless you're using a native library which 1. releases the GIL and 2. is broken.
- pohl 4y agoInteresting, I hadn’t realized how much the phrase “memory safety” understates what is desirable.
- gpm 4y agoThe thing is that races are good a lot of the time. If I have a set of tasks running in parallel that take an unknown/variable amount of time and I want to tell the users which ones are finished, my output needs to be based on a race between the tasks. If I'm scraping a website, I (may) want to have multiple connections going in parallel, and as soon as one of those connections spots a new link I (may) want to open a new connection to start scraping it, but I don't know which connection is going to spot a new link first, so there's a (benign) race condition. Making a language that banned them outright would be making a language that couldn't do things that people wanted to do.
- Yoric 4y agoI figure that you could very easily mark which race conditions are good.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- gpm 4y agoMatter? Sure, there can be race conditions. But allow for memory unsafety? No, not if every ordering of the "critical sections" (chunks of code run as a unit while the interpreter is locked) is valid and upholds the invariants Python expects.