This is causing a data race because you may get a `SIGCANCEL` from another thread before before you install the cancellation handler. While it's true that the consequences of this data race are not grave, they may "only" induce a performance hit in the worst case, it's probably not a good idea to allow that. This code tries to provide a remedy for an issue that went unnoticed in glibc for years and hit EOS pretty hard. Look at how these functions are implemented. `pthread_cancel_push` and `pthread_cancel_pop` are essentially: ``` do { _pthread_cleanup_class __clframe (routine, arg) // your code goes here } while(0); ``` where `_pthread_cleanup_class` is essentially the same as `XrdSysMutexHelper`. https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/nptl/pthread.h;h=fd0894efd210933791e4f89cb8af709b545dcb93;hb=HEAD#l548 As for `pthread_setcanceltype`, it essentially does: ``` cancelhandling |= CANCELTYPE_BITMASK; ``` and checks if the thread should be cancelled immediately. https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_setcanceltype.c;h=442211cd8110ca4db2cce1142a61d9268082ffb5;hb=HEAD I am sure there is a better solution, even if it has to be a different combination of these. --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/321#issuecomment-169944361 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1