Re: PTHREAD_CANCEL_HURD

[Richard Braun]

On Fri, Aug 03, 2012 at 01:18:43PM -0700, Roland McGrath wrote:
> I see.  So the meaning of the new type is that normal cancellation
> handling is never triggered, instead the "cancelled" flag can only be
> polled by the explicit check API.  What do cancellable functions do,
> then?  Do they just fail with ECANCELED while leaving the cancelled
> flag set?

How would that make Hurd servers behave ? Would client receive the
ECANCELED error ? Isn't it better to just completely ignore the
cancellation everywhere except where hurd_condition_wait is called, as
it is done currently ? Except from the increased latencies (which can
easily be fixed by adding new hurd_condition_wait calls), I don't see
any issue with that, while I suspect some applications could react
angrily when meeting unexpected ECANCELED results.

> I'd call this new type by a name that's descriptive of what it means,
> rather than what programs are expected to use it.  For example,
> PTHREAD_CANCEL_POLLED.

Could it hurt portability (not that I know of any other system using
glibc that uses such tricks, but still) ?

-- 
Richard Braun