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
