From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave <dave@dave.tj>
Subject: Re: [9fans] blanks in file names
In-reply-to: <9e269d17ee7ea1cd7ecd77a8a58705ff@collyer.net>
To: 9fans@cse.psu.edu
Message-id: <200207141813.g6EIDmw28998@dave2.dave.tj>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Date: Sun, 14 Jul 2002 14:13:47 -0400
Topicbox-Message-UUID: cb7ac8d2-eaca-11e9-9e20-41e7f4b1d025

Reply inline:

 - Dave

Geoff Collyer wrote:
> 
> dave@dave.tj,
> 
> Have you actually used Plan 9 or even read its manual?  I ask because
> you've made a succession of odd statements:
Yup, I had Release 3 on an old system (which I tried to upgrade to Release
4, to no avail), although I must admit that it wasn't my preferred
platform.  Everything from the directory structure to the process of
trying to compile standard UNIX-compatible software was extremely awkward.
I was hoping to give Release 4 a try, but until I can get the Millenium
(or the Blade 3D, my only other card) to work with Release 4, I'm out
of luck.  As for the manual, no way ... I never read the manual until
I run into trouble ;-P

> 
> > strlen() is an expensive operation.
> 
> No, it's not terribly expensive.  Even if it were, most strings are
> short, so it's not much of an issue.  DES encryption is expensive.
It must examine every byte in the array, and that's an expensive
operation.  DES must examine every byte multiple times, so it's a very
expensive operation.  The structure method doesn't require access to
every byte in the array, since the length is counted.

> 
> > realloc() sucks in a multithreaded environment.
> 
> You don't define ``sucks'', but the whole malloc family use internal
> locks on Plan 9 so that they *do* work well (or at least don't corrupt
> memory) in multiprocess or multithread programs.
Yup, I should've defined "sucks" - here goes:
suck - v. being rediculously inefficient, due to the need to move the
realloc(3)ed chunk almost constantly, because realloc(3) isn't smart
enough to know that another realloc(3) in another thread is also growing
a block, and realloc(3) hates stepping on other realloc(3)s' toes

(BTW - realloc(3) can also suck in a single-threaded environment (two
arrays that are growing in the same thread), but it's more common
for it to be used in a way that causes it to suck in multi-threaded
environments.)

> 
> > Also, I'd like to mention again that I'm not asking the kernel to
> > allocate memory.
> 
> The kernel already allocates memory, including string memory.  What's
> the big deal?
AFAIK, the kernel does _not_ allocate userland memory with anything
but the brk(2) call - which is only called by malloc(3), realloc(3),
and operator new().  Please correct me if I'm wrong.

>