Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> We can talk about this for the Hurd (I think we can do fine with a small
> interface change), but at least in the dynamic linker there has to be a
> recursive lock (there is a XXX in the code for that, we will deadlock on the
> second invocation. Bu
On Sun, Jul 08, 2001 at 12:38:39PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > In the fully unlocked state, RL->locking_thread is MACH_PORT_NULL.
> > How can this match mach_thread_self() of thread 1?
>
> Oh, I take it back. Hrm, it appears that your
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> In the fully unlocked state, RL->locking_thread is MACH_PORT_NULL.
> How can this match mach_thread_self() of thread 1?
Oh, I take it back. Hrm, it appears that your implementation is fine
after all sorry! :-/
I do still think that using recur
On Fri, Jul 06, 2001 at 10:08:25AM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> > > Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > >
> > > > We agreed, in an inspiring coordinated
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> > Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> >
> > > We agreed, in an inspiring coordinated coding effort, on the following
> > > implementation (thanks to Johannes, Neal, M
On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > We agreed, in an inspiring coordinated coding effort, on the following
> > implementation (thanks to Johannes, Neal, Moshe and Rene):
>
> No, that still has a race condition
> The state of the code is the most of the functionality is already
> implemented, except for the part of the thread instantiation code
> that deals with signals. I'm once again, faced with a lack of
> documentation reguarding `hurd_sigstate' and friends. I don't mind
> reading the relevant bits o
On Thu, Jul 05, 2001 at 10:51:21AM -0500, Marcus Brinkmann wrote:
> On Wed, Jul 04, 2001 at 06:13:23PM -0700, Thomas Bushnell, BSG wrote:
> >
> > Maybe I missed something, but what specifically is this for?
>
> You are missing out the LSM, a great event. Many greetings from Bordeaux!
>
> Mosh
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The C library needs recursive locks for the dynamic linker (loading object
> files at run time), and they might be quite useful in libraries, too
> (for better modularization).
Incidentally, it is my opinion that recursive locks don't improve
modula
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> We agreed, in an inspiring coordinated coding effort, on the following
> implementation (thanks to Johannes, Neal, Moshe and Rene):
No, that still has a race condition as follows. We begin in the fully
unlocked state.
THREAD 1
On Wed, Jul 04, 2001 at 06:13:23PM -0700, Thomas Bushnell, BSG wrote:
>
> Maybe I missed something, but what specifically is this for?
You are missing out the LSM, a great event. Many greetings from Bordeaux!
Moshe asked about recursive locks today, which we don´t have. He said
it is easy to
[EMAIL PROTECTED] (Niels Möller) writes:
> I think a "recursive mutex" usually refers to a lock that keeps track
> of an owner and a count.
Well, that's what I usually think too. :) But it isn't close to what
the posted functions do. :)
___
Bug-hur
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What are the expected semantics of this function? (A complete
> implementation of something always includes explanatory comments.)
I think a "recursive mutex" usually refers to a lock that keeps track
of an owner and a count. recursive_lock()
Maybe I missed something, but what specifically is this for?
Anyway, on to more substantive comments:
[EMAIL PROTECTED] writes:
> struct recursive_lock
> {
> spin_lock_t protection;
> int locked;
> struct mutex mutex;
> };
What is the separate "protection" bit for?
> void
> recursive
14 matches
Mail list logo
