3 ms·

pthread cancellation was a terrible idea when it was added, and it's even worse today. It's an API that provides no actual value (you can implement it yourself

pthread cancellation was a terrible idea when it was added, and it's even worse today. It's an API that provides no actual value (you can implement it yourself via signals), is a giant minefield if you care about not leaking or deadlocking, and infects the entirety of libc with pointless checks for functionality that no one in their right mind should use.

yc12340 7y ago
> pthread cancellation was a terrible idea when it was added, and it's even worse today > you can implement it yourself via signals It appears, that you are contradicting yourself. Either it is "bad idea" or it is easy to correctly implement by oneself, not both. musl has well though-out implementation of pthread cancellation, so it is clearly doable, even if glibc developers have failed at it.
- murderfs 7y ago
  The problem with pthread cancellation is that it is fundamentally broken when used on a thread that can ever acquire resources (opening an fd, taking a mutex, mallocing a buffer, etc.). If it were just "call pthread_testcancel to figure out if you were cancelled", that would be fine, but no, you either get blown up immediately, or you get blown up at arbitrary function call boundaries (that don't really make any sense; e.g. why is strerror_r allowed to be a cancellation point?) It's easy to correctly implement the parts that aren't just adding a call to pthread_testcancel to every single syscall wrapper, just reserve an RT signal and do your thread teardown when you receive it, using pthread_sigmask to implement enable/disable. It's just that it's just a terrible idea.
  - dfox 7y ago
    strerror[_r]() is allowed to be cancellation point, because it's implementation may involve calls to read() which is required to be cancellation point.
saagarjha 7y ago
> It's an API that provides no actual value (you can implement it yourself via signals) > is a giant minefield if you care about not leaking or deadlocking Aren't these two in opposition?
- murderfs 7y ago
  No. pthread_cancel implemented completely correctly is inherently a giant minefield. (Details in a reply to a sibling post)

yc12340 7y ago

> pthread cancellation was a terrible idea when it was added, and it's even worse today > you can implement it yourself via signals It appears, that you are contradicting yourself. Either it is "bad idea" or it is easy to correctly implement by oneself, not both. musl has well though-out implementation of pthread cancellation, so it is clearly doable, even if glibc developers have failed at it.

murderfs 7y ago
The problem with pthread cancellation is that it is fundamentally broken when used on a thread that can ever acquire resources (opening an fd, taking a mutex, mallocing a buffer, etc.). If it were just "call pthread_testcancel to figure out if you were cancelled", that would be fine, but no, you either get blown up immediately, or you get blown up at arbitrary function call boundaries (that don't really make any sense; e.g. why is strerror_r allowed to be a cancellation point?) It's easy to correctly implement the parts that aren't just adding a call to pthread_testcancel to every single syscall wrapper, just reserve an RT signal and do your thread teardown when you receive it, using pthread_sigmask to implement enable/disable. It's just that it's just a terrible idea.
- dfox 7y ago
  strerror[_r]() is allowed to be cancellation point, because it's implementation may involve calls to read() which is required to be cancellation point.

saagarjha 7y ago

> It's an API that provides no actual value (you can implement it yourself via signals) > is a giant minefield if you care about not leaking or deadlocking Aren't these two in opposition?

murderfs 7y ago
No. pthread_cancel implemented completely correctly is inherently a giant minefield. (Details in a reply to a sibling post)