▲ | gpderetta 4 days ago | ||||||||||||||||||||||
Ok, partially evaluate the interpreter against a python always-deadlocking program. Now it no longer implement arbitrary logic, but it is a very specific program. Yet it deadlocks. So what does it means that Pony is deadlock free if it can implement deadlocking programs? A better, more rigorous claim would be that the pony runtime is deadlock free or that there are no primitive blocking operations. | |||||||||||||||||||||||
▲ | perching_aix 4 days ago | parent [-] | ||||||||||||||||||||||
Within the context of your Pony program you'll never be deadlocked. The virtual machine you implement capable of universal compute, and not enforcing this constraint, can be internally deadlocked, but this doesn't prevent your other Pony code from progressing necessarily - the deadlock is an internal state for that virtual machine, formally guaranteed to be confined to it. I'd be hesitant to call this a "Pony runtime" property - to my understanding language runtimes just provide application bootstrapping and execution time standard library access. Pony code becomes machine code, managed by the OS as a process with some threads. This language property guarantees you that those threads will never "actually", "truly" deadlock. Code implemented on the Pony level can still progress if it chooses to do so, and Pony formally ensures it always has the option to choose so. If your business requirements necessitate otherwise, that's a different matter, something you introduce and manage on your own. | |||||||||||||||||||||||
|