4 ms·

No i'm not sure, that's just what i understood from reading the article, which only mentions race conditions and something looking like a deadlock. You think it

• dahart 4y ago
  > You think it could be a deadlock in the the memory allocator? Absolutely it could be allocator related! I didn’t suggest it was “in the allocator” specifically, but regardless the answer is absolutely yes in the absence of any other information, it absolutely could be failing to make progress due to the memory allocator, in the allocator, or due to the garbage collector or interactions with the garbage collector (assuming they had gc), or it could be interactions between the user space code and the library/kernel memory management code. You can Google “memory allocation deadlock” and notice how many results you get. Add “lisp” to your query and you’ll even find modern examples of it. (But note that because library code was involved, and because they were transpiling lisp into machine code and not using the lisp run-time, the reason for deadlock could be related to non-lisp code.) The programs could have unknowingly used a non-thread-safe allocator, they could have been low on memory causing a free-alloc type of deadlock, or they could have caused deadlock in their own code managing which thread or process was trying to allocate memory. Any of these scenarios are reason enough to conclude, like they eventually did, that using dynamic memory is dangerous for safety critical systems. Even just the temptation to reach for a library function is something a higher level language encourages, right?