Denis Oliver Kropp wrote:
Claudio Ciccani schrieb:Denis Oliver Kropp wrote:Claudio Ciccani schrieb:Denis Oliver Kropp wrote:But pthread_cancel() also terminates the thread at mutex_lock for example which would be bad if a lock is already taken. I'd prefer having well chosen voluntary exit points.That can be avoided by using a similar procedure: pthread_setcancelstate(PTHREAD_CANEL_DISABLE) // // safe calls ... // pthread_setcancelstate(PTHREAD_CANCEL_ENABLE) // process pending cancelations pthread_testcancel() According to me, the problems you are encountering suggest that pthread_cancel() should not be removed.The DI guys prefer to not add a needed extra library (on AMD64), but replace those calls.But an ordinary system have that library installed! We could provide a patch for Debian, but we should not change DirectFB main code accoring to me.That's what I thought :) But your suggestions to guard the code outside the blocking read() by disabling (or better defering) cancelation are good.
IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call?
cheers Attilio