EAD_CANCEL_GNU? It would be doable.
I would personally name it PTHREAD_CANCEL_HURD to avoid increasing the
already existing confusion.
> If that were the case, we could merge hurd_condition_wait into
> phread_cond_wait as a special case. Maybe: streamio
> intermingles the two, p
hat the server threads never stop because of an unexpected cancellation
>point. One way that comes to my mind is to disable cancellation by
>default in Hurd server threads, and making pthread_cancel ignore that
>state (i.e. still mark such threads as being cancelled). Normal
>cancellation
Hurd). And as I said earlier, even if the
implementation varies, it does only slightly, as you confirmed it. The
only relevance of this difference is for the new hurd_condition_wait
function, obviously.
> Here is the declaration of hurd_thread_cancel from glibc's hurd.h:
> /* Cancel pendi
>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
nt calls to hurd_condition_wait (i.e. through plain error handling)
than try to replace that with complicated cleanup callbacks.
> My understanding is that hurd_condition_wait is used with hurd_thread_cancel
> in libc, as libc uses a different cancellation semantics than is provided by
> PO
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
I was checking old hurd code and I saw that on the glacial age, Hurd
simply used thread_cancel and condition_wait, but on that date a
mysterious migration to hurd_thread_cancel and hurd_condition_wait
happened.
What I really wanna know is why this change were necessary, since this
may help me on
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
e do not use this and I have no reason to believe it is necessary.
> -hurd_condition_wait (condition_t c, mutex_t m)
> +hurd_condition_wait (pthread_cond_t c, pthread_mutex_t m)
You still have not fixed this.
>void cancel_me (void)
> {
> - condition_broadcast (c);
>
Can a thread be waken up if it hasnt been blocked?
>
> pthread_state has nothing to do with that. Threads are put to sleep
> via __pthread_block and awoken with __pthread_wakeup.
>
I attach here a diff of another hurd_condition_wait example.
Is there a race condition before __pthre
> 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
d_wait.
That is okay. Remember, we are just queuing a message so it will be
there when we do the actual wait.
> c) A different implementation using __pthread_enqueue function.
This should be done anyways.
> At the end there is the original hurd_condition_wait function
> attach
Hi all!
The following is a hurd_condition_wait replacement with pthread code.
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.
hurd_pthread_cond_wait function:
/* Just like
18 matches
Mail list logo
