[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PTHREAD_CANCEL_HURD
From: |
Richard Braun |
Subject: |
Re: PTHREAD_CANCEL_HURD |
Date: |
Fri, 3 Aug 2012 22:32:04 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- PTHREAD_CANCEL_HURD, Thomas DiModica, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD,
Richard Braun <=
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/11
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/11
Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/07