rachamp@mbunix.mitre.org (Richard A. Champeaux) (07/13/89)
This may not be a new revelation, but I figured I'd post it since I haven't seen any mention of it yet. While writing PLT:, I've found myself rebooting the computer every time I make a change so that the new version will be loaded into memory. This can happen very often when I'm chasing down a bug by adding debug messages. In his example ram disk handler, Matt Dillon's solution to flushing out the handler was a program to allocate all the memory, hoping to cause exec to flush it. In a POSTTER file, he said that may not work after all and suggested using multiple mountlist entries. I figured there had to be a better way, dug out a program I had written to print out the system device list, and modified it to do the job. Basically, I search the device list for an entry matching the name I give it. It checks the dvi_Type field to make sure it's a device and not a logical assign or volume, then it checks the dvi_Task field to make sure it's not currently running. Lastly it checks the dvi_SegList field to see if it's really in memory. If it passes those three checks, then the program calls UnLoadSeg(), and sets e dvi_SegList to NULL. The next time DOS tries to access the handler, it sees that it's not loaded, and loads the new version. The only problem is that it will only work for handlers that set the dvi_Task field. Handlers like the console handler supposedly don't do this, and the program will think the code is not in use. Unloading the handler code while it's in use is not recommended. I supppose there's probably a way to figure out if the code is in use, but that's currently beyond my knowledge. I imagine that this program can be taken a step further to make it an unmount command by also deleting the DevInfo node from the device list. Anyways, the program works just nifty with PLT:. Rich Champeaux (rachamp@mbunix.mitre.org)
papa@pollux.usc.edu (Marco Papa) (07/16/89)
In article <59256@linus.UUCP> rachamp@mbunix.mitre.org (Champeaux) writes: >While writing PLT:, I've found myself rebooting the computer every time >I make a change so that the new version will be loaded into memory. This >can happen very often when I'm chasing down a bug by adding debug messages. >In his example ram disk handler, Matt Dillon's solution to flushing out the >handler was a program to allocate all the memory, hoping to cause exec to >flush it. In a POSTTER file, he said that may not work after all and suggested >using multiple mountlist entries. Matt's solution worked for me. I am developing XPR-based external protocol libraries. When I make a change after I run the external protocol library, I select another protocol (which produces a CloseLibrary, and the use count goes to zero). Then I run FlushAll (see later). I check with Xoper's lib command that the library is flushed and then test the new library after having it copied to LIBS:. I know the same works for devices and I see no reason why it shouldn't work for handlers. Here is the stupid code for that: #include "stdio.h" #include "exec/types.h" #include "functions.h" main() { char *ptr; ptr = (char *) AllocMem(16000000L, 0L); /* cause the expunge */ if (ptr != NULL) FreeMem(ptr, 16000000L); } Note that this code should NOT be included at the end of a program to force a "global" expunge to satisfy all the reviewers that run AvailMem to check if a program frees all the resources it has allocated. Jimm will hang you for that :-) I was doing that in A-Talk III (yes, I repent :-). The next version will use the newly-"recommended" way of expunging the serial device "by name" (see Bryce Nesbitt example in AmigaMail). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jimm@amiga.UUCP (Jim Mackraz) (07/17/89)
In article <18551@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: )In article <59256@linus.UUCP> rachamp@mbunix.mitre.org (Champeaux) writes: )>While writing PLT:, I've found myself rebooting the computer every time )>I make a change so that the new version will be loaded into memory. ){ ) char *ptr; ) ) ptr = (char *) AllocMem(16000000L, 0L); /* cause the expunge */ ) if (ptr != NULL) FreeMem(ptr, 16000000L); )} In commodities.library I just rigged it so that when the OpenCnt goes to zero, I expunge myself. Now, how do I do that? I guess I'll have to check. Anyway, that means that while testing I can easily assure that I'm getting a new copy off the disk. Depending on the expected use of a library, leaving such code in by mistake isn't that bad. Commodities.library is used for "TSR" style programs: once open, it typically will not ever see OpenCnt == 0. )Note that this code should NOT be included at the end of a program to force )a "global" expunge to satisfy all the reviewers that run AvailMem to check )if a program frees all the resources it has allocated. Jimm will hang you for )that :-) No, I'll scold them. It's *you* I'll hang for posting this code fragment ;^) ;^) ;^) )-- Marco Papa 'Doc' jimm -- Jim Mackraz, I and I Computing "... the signs are very ominous, {cbmvax,well,oliveb}!amiga!jimm and a chill wind blows." - Justice Blackmun Opinions are my own. Comments are not to be taken as Commodore official policy.
papa@pollux.usc.edu (Marco Papa) (07/17/89)
In article <4118@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >In article <18551@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >)Note that this code should NOT be included at the end of a program to force >)a "global" expunge to satisfy all the reviewers that run AvailMem to check >)if a program frees all the resources it has allocated. Jimm will hang you for >)that :-) > >No, I'll scold them. It's *you* I'll hang for posting this code fragment ;^) ;^) ;^) I knew it. Jimm has been too much involved with this week's "French Revolution" festivities :-) ;^) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
new@udel.EDU (Darren New) (07/18/89)
My solution (when trying to get my MountList right) was to use the ASSIGN dh0: REMOVE command. It seems to remove the thing from the mountlist without otherwise deallocating, etc. (1.3 only) Of course, eventually you will run low on memory and need to reboot, but for quick tests this can be useful. -- Darren
new@udel.EDU (Darren New) (07/18/89)
Note that if you start workbench with debug (loadwb -debug) then the debug menu to the right of the special menu will have a flushlibs that tries to allocate all the memory. If you want to expunge your library every time you test it, simply call Expunge just after you OpenLibrary. When the use count goes to zero, your library should check and deallocate itself. When Exec runs out of memory, it seems to call expunge on all the libaries (causing them to flush if zero count) and then retry. Of course, I don't know if this works for handlers, but all this stuff is already there for you in the case of libaries. -- Darren
kodiak@amiga.UUCP (Robert R. Burns) (07/18/89)
... back to the original thread: remember that the message port (a.k.a. dn_Task) of your handler is made available to anyone scanning the device list or calling DeviceProc(). Although you can flush your own handler in a development environment where you have some certainty that this port has not been cached by some other application, flushing it in a product is a guru pheromone. - Kodiak -- Bob Burns, amiga!kodiak _ | /_ _|. _ | Commodore __ |_) _ |_ _ )' |<(_)(_)|(_\|< /\ | ||| _` /\ |_)(_\| )(_\ | | \ Software ___/..\|\/|||__|/..\___ Faith
walker@sas.UUCP (Doug Walker) (07/18/89)
In article <59256@linus.UUCP> rachamp@mbunix.mitre.org (Champeaux) writes: >I imagine that this program can be taken a step further to make it an unmount >command by also deleting the DevInfo node from the device list. Under AmigaDOS 1.3: ASSIGN PLT: REMOVE does exactly that. It doesn't unload the handler code, though, so it's only useful during program development. I suggest putting a back door msgport in your handler that lets you force it to give up its resources (as much as possible) and die. --Doug
451061@UOTTAWA.BITNET (07/19/89)
> From: "Robert R. Burns" <kodiak@amiga.uucp> > Newsgroups: comp.sys.amiga.tech > Subject: Re: Flushing handlers out of memory. > Message-ID: <4174@amiga.UUCP> > Date: 17 Jul 89 20:36:15 GMT > Organization: Commodore-Amiga Inc, Los Gatos CA ^^^^^^^^^ Gee, I thought the Los Gatos offices had been closed down 2 years ago. Is that not so? Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
jesup@cbmvax.UUCP (Randell Jesup) (07/20/89)
In article <1110@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >does exactly that. It doesn't unload the handler code, though, so it's only >useful during program development. I suggest putting a back door msgport in >your handler that lets you force it to give up its resources (as much as possible) >and die. Don't ever let the process die. Someone may have DeviceProc'ed you, and may send you a packet at any time. At absolute most, free up resources and all code but a fragment that waits on the pr_MsgPort and replies all messages with errors. 1.4 will address usage counts for handlers. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"