On Fri, Aug 03, 2012 at 01:44:54PM -0700, Roland McGrath wrote:
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.)
What would you recommend we name
On Sat, Aug 11, 2012 at 07:42:27PM +0200, Richard Braun wrote:
On Fri, Aug 03, 2012 at 01:44:54PM -0700, Roland McGrath wrote:
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
On Mon, Aug 06, 2012 at 07:07:23PM -0700, Thomas DiModica wrote:
I understand now: we want to immediately dequeue ourselves, even if it means
wasting cycles later by checking to ensure that we were dequeued. The last
thing we want is to return ETIMEDOUT when another thread has intervened,
and
On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote:
I was thinking about what Richard Braun said about removing
hurd_thread_cancel.
Attached is an exploration into implementing PTHREAD_CANCEL_HURD as a
cancellation state extension. It compiles, but I haven't tested
Sometimes, I ask questions early, without thinking for myself of the answers:
PS. In timedwait, we dequeue the thread, but the cleanup handler (which is
always run) ensures that the thread is dequeued also. Is this necessary, or
just an artifact that is due to how all of the timed functions
I was thinking about what Richard Braun said about removing hurd_thread_cancel.
Attached is an exploration into implementing PTHREAD_CANCEL_HURD as a
cancellation state extension. It compiles, but I haven't tested if the
resulting library
still works.
A server would call pthread_hurd_server_np
On Fri, Aug 03, 2012 at 12:50:29PM -0700, Roland McGrath wrote:
Why add a new cancellation type? PTHREAD_CANCEL_DEFERRED is already fine.
You just need an extension function that is like pthread_testcancel but
clears and returns the state instead of triggering cancellation handlers.
The
The problem with that is, if a Hurd server internally calls a function
that is a cancellation point, the calling thread will automatically exit
before having a chance to reply to the client. A Hurd-specific type
should allow the safe use of more standard functions.
I see. So the meaning of
On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote:
There are interesting implications for this, however. pthread_join becomes a
function that may eat a signal to cancel. The main implication is,
essentially,
that every occurrence of condition_wait becomes a call to
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
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
On Fri, Aug 03, 2012 at 01:44:54PM -0700, Roland McGrath wrote:
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
12 matches
Mail list logo
