From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1efd3e96278a7f66f6aad74867866f19@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Wed, 21 Mar 2007 11:59:01 -0400
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fossil errors
In-Reply-To: <9ab217670703210853g2b268bc6w1bfde7b6538af507@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 2b16274e-ead2-11e9-9d60-3106f5b1d025

fossil should never do this.  this is a thread locking bug.

btw, why not use "all=+; disk/mkfs -vd $dst -s $src /env/all"?

- erik

On Wed Mar 21 11:54:29 EDT 2007, devon.odell@gmail.com wrote:
> 2007/3/21, erik quanstrom <quanstro@coraid.com>:
> > it means that lock() (/sys/src/9/port/taslock.c:/^lock) is looping way too much
> > in rendezvous.  0x37a34 is in rendezvous.s.
> >
> > i don't know fossil or venti very well.  it would be hard to say what is wrong with
> > the threading here without some serious groveling.  my wild guess would be that
> > there are three processes (21 26 23) at the same rendezvous point at the same time.
> > rendezvous works for two processes.
> >
> > i wonder why libventi doesn't use the thread library?
> 
> In either case, it doesn't seem to happen very often. I got it by @{
> cd ; tar -c . } | tar -xv ing my MP3s. So far, using cpdir, I haven't
> seen any of this yet.
> 
> --dho