karron@KARRON.MED.NYU.EDU (11/10/90)
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 )| +-----------------------------------------------------------------------------+
karron@KARRON.MED.NYU.EDU (11/12/90)
>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 )| +-----------------------------------------------------------------------------+
robert@texas.asd.sgi.com (Robert Skinner) (11/14/90)
In article <9011111657.AA07555@karron.med.nyu.edu>, karron@KARRON.MED.NYU.EDU writes: |> Can I use the shared gl (gl_s) with the unshared mpc library ? |> |> Cheers! |> |> Dan |> certainly, just give it a try, and you'll see smaller executables. Robert Skinner robert@sgi.com Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were forced to live on nothing but food and water for days. - W. C. Fields, "My Little Chickadee"