FYI
ftp://ftp.ac.upc.es/pub/archives/gso/mach.OSF/os_coll_papers/server_colocation_design.ps
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 u
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.
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
> 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: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
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
> 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: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
Thomas DiModica, le Mon 30 Jul 2012 16:17:20 -0700, a écrit :
> The fix seems to be to change the line to read:
> inst_libdir = $(libdir)
Indeed, commited, thanks!
Samuel
10 matches
Mail list logo
