3 ms·
"It mostly works for simple programs, but probably segfaults on anything complicated" is not a promising beginning. Starting with race condition chaos and tryin
by twoodfin 9y ago
"It mostly works for simple programs, but probably segfaults on anything complicated" is not a promising beginning. Starting with race condition chaos and trying to patch your way out of it with "strategic" locking
a) Inspires much less confidence than starting with a known-correct locking model (the degenerate case being a GIL) and preserving it while improving available concurrency.
and
b) Seems at least 50/50 to end up without much in the way of tangible scalability gains once enough locking has been added to reduce the rate of crashes and data corruption to an acceptable (?!) degree. At least that was my takeaway from all the challenges Larry Hastings has documented while working on the gilectomy. Sure, they don't have to worry about locking around reference counting, but it's not like writing a (concurrent?) GC operating against concurrently executing threads isn't a significant design challenge itself with many tradeoffs to make.
- mcherm 9y ago> "It mostly works for simple programs, but probably segfaults on anything complicated" is not a promising beginning. Perhaps they would have done better to say "it works correctly for all programs that do not assume the built-in data structures are threadsafe". That is an accurate description, what you quoted is a reasonable approximation.
- fijal 9y agoThe concurrent garbage collector has been already written. It probably has bugs, but the basis has been done for the STM effort and redone now. The mess of race conditions is surely not a great place to start, which is why it would take a man year to finish :-) I don't see a much better starting point tbh, but to look at all the mutable data structures in python (of which there are too many) and try hard