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.

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