After pondering the issue some more, I fail to see what impact
setjmp()/longjmp() actually have on thread cancellation.
The cancellation stack is simply a list of routines that must be invoked at
certain times. Although it might be interesting from a maximum stack-usage
point of view to unwind the stack to the frame that has registered a
cancellation handler before invoking that cancellation handler, this is an
(probably not terribly important) optimization which need not be implemented
via setjmp()/longjmp(). I see no other reason for using setjmp()/longjmp()
in cancellation handlers. Issues might exist for C++, but that is
out-of-scope for POSIX.
On the other hand, if the issues for C++ (exceptions) require
setjmp()/longjmp() handling on platforms without additional exception unwind
info even for C routines, then I think it would be in order for POSIX to
require the argument passed to the cleanup routine to be qualified as
volatile.
On the third hand, it is probably the case for C++ exception handling that
the longjmp() back into exception catching routine needs to be done only for
routines that actually catch exceptions, which are C++ anyway, and C++
apparently is able to avoid the need for volatile qualification.
Regards,
Konrad Schwarz
|