Ludovic Courtès <[EMAIL PROTECTED]> writes:
> On Mon, Jan 06, 2003 at 08:49:23PM -0800, Thomas Bushnell, BSG wrote:
> > This is incorrect behavior for netfs_attempt_unlink. There is nothing
> > wrong with unlinking a node that still has other references, and if
> > this is done, you must not actu
--- Danilo_©egan <[EMAIL PROTECTED]> wrote:
> I have Internet connection currently only on a Windows PC, so I must use
> Windows CVS version.
>
> When it comes to directory "aux", it fails because "aux" is, I believe,
> a special name in DOS and later. Since I didn't see in ViewCVS any
> conte
hello people, hello marcus.
happy new year.
[i met marcus in bristol last year]
well i decided to try to get gnu/hurd running again
after the disaster attempts at network connections.
my laptop (sony vaio pcg-z600hek) has a built-in
eepro100 and... well... it wasn't recognised, and
updating the
Ludovic Courtès <[EMAIL PROTECTED]> writes:
> In libnetfs, the netfs_nref, netfs_nput, etc. functions use a global spin
> lock that they acquire before changing the reference count of a node.
> First of all, it is not clear to me why the lock needs to be global.
A global is harmless, because the
I have Internet connection currently only on a Windows PC, so I must use
Windows CVS version.
When it comes to directory "aux", it fails because "aux" is, I believe,
a special name in DOS and later. Since I didn't see in ViewCVS any
content in this directory, I decided to skip it, and download
On Mon, Jan 06, 2003 at 08:47:23PM -0800, Thomas Bushnell, BSG wrote:
> mutexes and spin locks behave identically. The only significant
> difference is the respective performance costs of contention and
> blocking.
Mutexes maintain a queue of waiting threads. I thought the goal of this
queue was
Ludovic Courtès <[EMAIL PROTECTED]> writes:
> On Mon, Jan 06, 2003 at 08:47:23PM -0800, Thomas Bushnell, BSG wrote:
> > mutexes and spin locks behave identically. The only significant
> > difference is the respective performance costs of contention and
> > blocking.
>
> Mutexes maintain a queue
On Mon, Jan 06, 2003 at 08:49:23PM -0800, Thomas Bushnell, BSG wrote:
> This is incorrect behavior for netfs_attempt_unlink. There is nothing
> wrong with unlinking a node that still has other references, and if
> this is done, you must not actually free any storage until all the
> references go a
Ludovic Courtès <[EMAIL PROTECTED]> writes:
> Consider the following case which is what happens when using "rm". On the
> client side (rm), the program takes the following steps when typing "rm x":
> 1. lookup "."
> 2. lookup "x"
> 3. close x (ie. mach_port_deallocate () the above port)
>
