On Thu, Aug 02, 2012 at 03:13:12PM -0700, Thomas DiModica wrote:
> I get what you're saying: I'm confusing the semantics of how cancellation
> is HANDLED with the semantics of how it is SIGNALED. The signaling
> semantics are the same.
That's it.
> You mean like a PTHREAD_CANCEL_GNU? It would be
>No, the semantics are the same. And you're saying it yourself :
>"hurd_thread_cancel kindly informs the thread that it has been
>canceled". The description of pthread_cancel is "The pthread_cancel()
>function shall request that thread be canceled. [...] The cancellation
>processing in the target t
On Wed, Aug 01, 2012 at 06:40:05PM -0700, Thomas DiModica wrote:
>
>
> >No, the semantics are the same. The internal implementation may slightly
> >differ, I haven't looked in detail. The point is how to handle
> >cancellation from a cancelled thread, not how to mark a thread as being
> >cancelle
>No, the semantics are the same. The internal implementation may slightly
>differ, I haven't looked in detail. The point is how to handle
>cancellation from a cancelled thread, not how to mark a thread as being
>cancelled. The hurd_thread_cancel function merely exists because there
>isn't any in
On Wed, Aug 01, 2012 at 08:44:20AM -0700, Thomas DiModica wrote:
> Most of what I understand is from what Marcus has to say in this thread here:
> http://lists.gnu.org/archive/html/hurd-devel/2002-07/msg00010.html
That link explains the problem very well. It's better to keep the
current calls to h
From: Richard Braun
To: Thomas DiModica
Cc: "debian-h...@lists.debian.org" ;
"bdefre...@debian.org"
Sent: Tuesday, July 31, 2012 4:48 PM
Subject: Re: Hurd_condition_wait in glibc libpthreads in Debian
On Tue, Jul 31, 2012 at 03:16:05PM -0700, Thomas DiModica wrote:
> A
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Sun, Nov 17, 2002 at 12:24:03PM -0500, Neal H. Walfield wrote:
> > > Is there a race condition before __pthread_block? We can receive
> > > pthread_broadcast before we have blocked.
> > > If so, how do we solve that?
> >
> > As I said in a previo
> > What about non-Mach backends? I would feel better about an
> > internal-interface-guarantee argument rather than an implementation
> > argument.
>
> This requirement is part of the interface; I was using Mach for
> illustration purposes because I assume that Vincente is familiar with
> Mach c
> Linux futexes have the exact same problem and they solve it similarly:
I should add that I have not looked at the latest implementation of
futexes. The description is based on my reading of Hubertus Franke,
Rusty Russell and Matthew Kirkwood's paper "Fuss, Futexes and
Furwocks: Fast Userlevel L
> What about non-Mach backends? I would feel better about an
> internal-interface-guarantee argument rather than an implementation
> argument.
This requirement is part of the interface; I was using Mach for
illustration purposes because I assume that Vincente is familiar with
Mach concepts. On,
On Sun, Nov 17, 2002 at 12:24:03PM -0500, Neal H. Walfield wrote:
> > Is there a race condition before __pthread_block? We can receive
> > pthread_broadcast before we have blocked.
> > If so, how do we solve that?
>
> As I said in a previous email, a __pthread_wakeup queues a message on
> the wai
> Is there a race condition before __pthread_block? We can receive
> pthread_broadcast before we have blocked.
> If so, how do we solve that?
As I said in a previous email, a __pthread_wakeup queues a message on
the waiter's port (using mach_msg). If this happens before the waiter
calls does a r
El dom, 17-11-2002 a las 16:30, Neal H. Walfield escribió:
> > Is there a replacement for CPROC_SWITCHING and CPROC_RUNNING in
> > cproc_t->state, to know if a thread has been waken up?
>
> No. We do not need it.
>
I should have sent more info last message.
> > Can a thread be waken up if it ha
> Is there a replacement for CPROC_SWITCHING and CPROC_RUNNING in
> cproc_t->state, to know if a thread has been waken up?
No. We do not need it.
> __pthread.state has the following states...
>
> /* Thread state. */
> enum pthread_state
> {
> PTHREAD_JOINABLE = 0,
> PTHREAD_DETACHED,
>
El sáb, 16-11-2002 a las 22:01, Neal H. Walfield escribió:
> > /* Just like pthread_condition_wait, but cancellable. Returns true if
> > cancelled. */
> > int
> > hurd_pthread_cond_wait (pthread_cond_t c, pthread_mutex_t m)
>
> I see no reason to rename this function.
As long as cthread and pth
> This would work assuming I can freely replace __spin_lock and
> __spin_unlock glibc functions by pthread_spin_lock and
> pthread_spin_unlock, and they are compatible.
You can.
> /* Just like pthread_condition_wait, but cancellable. Returns true if
> cancelled. */
> int
> hurd_pthread_cond_wai
16 matches
Mail list logo
