> Pthreads already has recursive locks as an X/Open extension, I don't
> think such changes are needed because we will switch to pthreads
> within a few months anyhow.
>
> Jeroen Dekkers
So what is in cvs is good for testing in a {sub,neighbour,n-}hurd?
=
James Morrison
University of Wa
On Tue, Jun 04, 2002 at 04:10:20PM -0700, Thomas Bushnell, BSG wrote:
> Marco Gerards <[EMAIL PROTECTED]> writes:
>
> > I thought about an other solution for the problem, although it is a stange
> > solution it might solve the problem. The thread in fatfs will deadlock
> > because that thread a
Marco Gerards <[EMAIL PROTECTED]> writes:
> I thought about an other solution for the problem, although it is a stange
> solution it might solve the problem. The thread in fatfs will deadlock
> because that thread already locked the node, what if the function that locks
> the node check if the
On Tue, Jun 04, 2002 at 10:12:37PM +0200, Marco Gerards wrote:
> > This was the change that came up on the thread "fatfs locking". It might
> > still be desireable for fatfs, but I don't know enough about that case to
> > really be sure.
>
> There is no fix for the fatfs locking problem yet. Thi
> This was the change that came up on the thread "fatfs locking". It might
> still be desireable for fatfs, but I don't know enough about that case to
> really be sure.
There is no fix for the fatfs locking problem yet. This patch can fix the
problem :).
I thought about an other solution for
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > Oops, that was something in my tree that I checked in by mistake.
> > I've reverted it (no log entry).
>
> Ooh, but illuminate... what's the idea behind it?
This was the change that came up on the thread "fatfs locking". It might
still be desi
* [Alfred M. Szmidt]
> Since when does diskfs_cached_lookup accept three parameters? From
> libdiskfs/diskfs.h.
> error_t diskfs_cached_lookup (int cache_id, struct node **npp);
>
> Snipet from the dir.c patch:
> @@ -198,7 +198,7 @@
>else
> {
> mutex_unlock (&dp->lock);
* Oystein Viggen writes:
> Roland: Can we get a 1.9 "finish reverting unintentional checkin for
> sure this time"? :)
Maybe Roland would be so kind to inform us all what this third
parameter to diskfs_cached_lookup is supposed to do. :)
Cheers,
--
Alfred M. Szmidt
* Roland McGrath writes:
> Oops, that was something in my tree that I checked in by mistake.
> I've reverted it (no log entry).
Either you forgot to fix the second mistake, or I forgot to tell you
about it. Care to tell us what this is supposed to do?
--- dir.c.~1.7.~Thu May 30 12:47:04
Roland McGrath <[EMAIL PROTECTED]> writes:
> Oops, that was something in my tree that I checked in by mistake.
> I've reverted it (no log entry).
Ooh, but illuminate... what's the idea behind it?
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail
Oops, that was something in my tree that I checked in by mistake.
I've reverted it (no log entry).
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
* Roland McGrath writes:
> CVSROOT: /cvsroot/hurd
> Module name: hurd
> Changes by: Roland McGrath <[EMAIL PROTECTED]> 02/05/28 19:57:10
> Modified files:
> tmpfs : dir.c tmpfs.c
> Log message:
> 2002-05-28 Roland McGrath <[EMAIL PROTECTED]>
> * dir
12 matches
Mail list logo
