> 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 ?
That's certainly not what's done currently. hurd_thread_cancel causes all "interruptible" RPC stubs to return EINTR, either by preventing the RPC from being made or by sending interrupt_operation RPCs to servers. This is the effect of the INTR_INTERFACE macro that appears in hurd/*.defs. (See libc/hurd/intr-msg.c, _hurdsig_abort_rpcs, etc.) This is the moral equivalent to the POSIX calls that are cancellation points. (The Hurd code predates the specification of pthreads by a few years, but it was designed according to the same concept of cancellation that lead to that part of the pthreads specification.) > > 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) ? I can't really imagine what issue you have in mind. To fit with the convention in NPTL for extensions, it should be PTHREAD_CANCEL_POLLED_NP. (The "_NP" suffix indicates it's a non-POSIX feature.) Thanks, Roland
