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" suff
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 na
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
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,
> a
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 functi
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
> 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 c
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 f
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 hurd_condi
> 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 o
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 pro
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.
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_serv
13 matches
Mail list logo
