PTHREAD_CANCEL_DEFERRED

[David Xu]

David Xu wrote:

>>> if you don't call testcancel() in close() stub like current libthr did,
>>> B won't response to the cancel request, you lost the race.
>> This situation should be handled by my proposal, since SIGCANCEL is
>> delivered only
>> - at the syscall entry point
>> - at the syscall premature return
>> Userspace would not get SIGCANCEL at time of [1], instead, signal will
>> be delivered at [2].
> kernel may don't know if the syscall is cancelable, because it depends
> on usage, if the close() syscall is used by fclose(), then the syscall
> is not cancellation point, libc avoids this by using _close(),
> and libthr does not override it. if kernel knows when a thread is at
> cancellation point, then it needs another syscall to set and unset
> the flag, but that's too expensive and in practical it is not
> acceptable.
> 
a bit out of topic, I also think that thread cancellation is not
better than a simple signal, because it does not return to caller
and force you to push and pop somethings, it may also be incompatible
with some language's exception handling, why does not just use
signal to interrupt syscall and let caller to check if the thread
should exit, the UNIX is quite good at this.