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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]