Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!ucbvax!KARRON.MED.NYU.EDU!karron
From: karron@KARRON.MED.NYU.EDU
Newsgroups: comp.sys.sgi
Subject: Re:  Arena California Dreamer
Message-ID: <9011111657.AA07555@karron.med.nyu.edu>
Date: 11 Nov 90 16:57:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu
Organization: The Internet
Lines: 75

>The reason the clobber data if usinit finds that noone is using the arena
>is to get around the problem of non-sophisticated users running a program
>more than once and saying that they cannot allocate any locks (cause
>all the old stuff is still allocated...)

I would like to ask that you make an option for usinit() or usconfig() to
allow me to save the program{s} state between invocations.

>
>I will fix the clearing of usgetinfo on clobbers.
>

Teriffic.
Then that location will be a reliable clue as to the {un}initalized
state of the arena. We could also use a default lock to prevent anyone else
from using the arena unless there is some value in the user area of the
arena. This property should also be settable/removable prior to arena
config. Just a quick way to insure that nobody makes a move on the arena
untill someone takes charge and sets things up.

>The magic number has been moved and the tidmap is now allocated dynamically
>(its also hashed - MAXUSERS is now 10000)
>

Good.

The only reason I would want to identify old arena files  is to clean them
up if they hang around more than a few days without being touched (I assume
that opening and closing the arena file descriptor updates
the directory entry).

>the arena is a mmaped file - so it is paged in as needed and gets paged back
>out to the file if memory gets tight. It does not use swap space.
>

What happens if you make a hugh arena, like 80 megabytes of so on a system
with (like mine) with 32 megabytes of memory ? I am allocating hugh blocks
of memory from regular memory management, while allocating smaller memory
blocks to use as program control blocks from shared Arenas.
The regular memory is washed back and forth in swap space. The arenas
are rolled in and out of their inode. Which is faster/better ? I thought swap
space io was extremely fast, faster than file system io.

Could you say a few words on the relationship between us{malloc,calloc},
a{malloc,calloc}, and {malloc,calloc,} ? What are the differences, design
goals, and reasons for the different flavors {us,a,,} ?

Is it safe to use the arena key as a base address to look into an arena ?
The documentation does not make any mention of this, and the only way to get
an address to look into an arena is from the usgetinfo or a us{{m,c,}alloc}
call. That was only obtained by default from the documentation. (i.e., it dont
say anything about this, but this is the most reasonable way)

My programs compiled with the -lmpc library are producing tremendous
executables. Are there any plans to make a shared mpc library ? Can I use
the shared gl (gl_s) with the unshared mpc library ? Any hope of an
user being able to make shared library in the near future ?

Thanks for your considered reply, and for your help.

Cheers!

Dan



+-----------------------------------------------------------------------------+
| karron@nyu.edu (mail alias that will always find me)                        |
|                                         Dan Karron                          |
| . . . . . . . . . . . . . .             New York University Medical Center  |
| 560 First Avenue           \ \    Pager <1> (212) 397 9330                  |
| New York, New York 10016    \**\        <2> 10896   <3> <your-number-here>  |
| (212) 340 5210               \**\__________________________________________ |
| Please Note : Soon to move to dan@karron.med.nyu.edu 128.122.135.3  (Nov 1 )|
+-----------------------------------------------------------------------------+