Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!mintaka!think.com!linus!agate!ucbvax!KARRON.MED.NYU.EDU!karron
From: karron@KARRON.MED.NYU.EDU
Newsgroups: comp.sys.sgi
Subject: Arena California Dreamer
Message-ID: <9011100756.AA03061@karron.med.nyu.edu>
Date: 10 Nov 90 07:56:01 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu
Organization: The Internet
Lines: 71


Well, actually, a New York dreamer.

>> I am allocating an arena, and each program that uses it checks the value
>> in usgetdata(). If it is zero, then assume that the arena is a virgin,
>> and the first thing that any of the programs do is setup a directory
>> of addresses for data structures inside the arena, and then uscalloc()
>> the data structures.
>>
>> I find that if all of the programs associated with an arena terminate, then
>> the data inside the arena is corrupted, deleted, or somthing, but the
>> value in usgetdata() is untouched.
>>
>> If I do an od of the data, I can see the strings that my programs left
>> behind, but something is wrong from the programs point of view.
>>
>> I would like an arena to preserve its state between programs. Is that
>possible ?
>>
>> An additional note: Is there anyway to identify arenas as special files ?
>> The file commands does not recognize then. I have not tried workspace default
>> sgi rules. Are they tagged ? Since I don't want to delete old arenas,
>is there
>> any way to clean them out if they are not touched for a day or so ? I know
>> that they don't use up disk space, but they do use up more valuable core.
>>
>
>The current design is that if upon a usinit it finds that no program
>is still attached to the arena it clobbers it - alas it doesn;t
>clobber the getinfo/putinfo location.

This strikes me as a design flaw: why corrupt user data, even if it
don't hurt anyone. If you insist of clobbering user data, then at least
leave me a clue at ushdr_info! Right now, I check what is pointed to by
ushdr_info (?=usgetinfo()). If that is null, then exit and remove the arena.
Is the bottom of memory clobbered to null so this is a reliable test ?
I would rather it worked right.

>being able to idnetify them with file(1) is a good idea.

I just tried to do you a favor and make an /etc/magic file entry for
0xdeadbabe (what an number... is that for real ? Someone had to stay
up real late to think of that in hex!). But with the _MAXUSUERS set so
high the offset into the file is 2052 bytes... too deep for find. You
really should put it at byte 0 or 1. You could also reduce the overhead by
making a dynamically allocated table with pointers for a LOT of user procs
in an arena!

>In fact they do use up disk space (as an ls -l) will show.

And they also use up core memory, right ? It would be really nice if you
allowed us to save the share core state as a file too. See my note above.

Is there any reason this can't be done ?

>
>Chris Wagner
>

Thanks for your reply.

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 )|
+-----------------------------------------------------------------------------+