set@calvin (09/17/88)
Okay, maybe my mind is permanently fused or I just don't understand the system that well, but I don't see why it should be so hard to track library opens/closes. By my understanding of the problem, if a task/process closes a library more often than it opened it, then the library can potentially be expunged out from underneath other programs using it. So we would like to automagically ignore the extra closes so the library's use counter won't go to zero (or worse) What's wrong with the following? 1. Near-term development/debug of code: create stubs (OpenLib()/CloseLib() for instance) which have identical semantics to OpenLibrary() and CloseLibrary() except for an internal list of libraries which are currently open. OpenLib() enters the opened library pointer into the list and CloseLib() only calls CloseLibrary() if the list says the library in question hasn't been closed yet. With a minor amount of coding discipline this should be almost painless. (There might be some work required in the startup modules and/or compiler libraries, but I wouldn't think it to be that bad) 2. Library developers: keep a list, rooted in the library's private data area, which has an entry for each program which has opened it. (Programs would be identified by a pointer to their task structure) Similar to #1, when the library gets opened it adds the task to the list and when the close entry is called, only decrements its usage counter if the task is still on the list. (At which point it is removed) I'm a bit fuzzy on how libraries are actually invoked, here I'm assuming (oh oh) that opens/closes are done while a task is executing, not somewhere in the background by Exec. A problem here is what to do if a task dies, but then what do we do now?, just leave the library open. 3. 1.4/1.5? Have the Exec routines perform the processing involved in #1 above for all tasks. The list would need to maintain task and library info, a combination of #1 and #2. The list could be rooted in the code which supports OpenLibrary() and CloseLibrary() as a shared structure, or a list of opened libraries could hang off the task structure. The nice thing here is that Exec knows when a task dies and could close libraries accordingly. Now I realize that this will cost some time, but how fast do we need to process opens/closes? Also, you could wind up really fragmenting memory if you don't do something intelligent about the list management but it's not that hard to allocate list structures in "clumps". Given the amount of discussion lately regarding this problem, I must be sniffing glue for it to seem so simple. Please show me the hole(s) in my argument, or if this isn't so crazy, let's see some implementations! ------------------------------------------------------------------------------- Scott Townsend ...[pyramid|decvax|masscomp]!abvax!set Polymath Corporation, currently working for (but not representing) Allen-Bradley Company 747 Alpha Dr. Highland Hts. OH 44143 USA (216) 646-4696
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/25/88)
:By my understanding of the problem, if a task/process closes a library :more often than it opened it, then the library can potentially be :expunged out from underneath other programs using it. So we would like :to automagically ignore the extra closes so the library's use :counter won't go to zero (or worse) : :What's wrong with the following? : :1. Near-term development/debug of code: create stubs (OpenLib()/CloseLib() : for instance) which have identical semantics to OpenLibrary() and The problem has been overrated... Sure it makes sense to check it when you are developing a program, but keep in mind that the system cannot check it under normal circumstances: - It can't be task/process based because it is perfectly acceptable for a task/process to open/close a specific library multiple times. For instance, commands run from the CLI use the CLI's task .. no new task is created to run the command unless you RUN it. - It can't be based on a process or segment because (1) a simple task might be making the open/close calls and (2) it might be desireable for the same segment to open the library multiple times. (For example, you make a library call and that library opens another library to do some stuff then closes the second library). - While program bugs may cause a library's reference count to go negative, it occurs to me that this would be a great place to put a 'recoverable guru'... because a negative reference count virtually assures the library will *never* be expunged anyway. However, libraries which allocate resources on the first ref and deallocate them on the last ref would be in trouble if the application software had such a bug. -Matt
dale@boing.UUCP (Dale Luck) (09/28/88)
In article <8809250355.AA24098@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > - While program bugs may cause a library's reference count to go > negative, it occurs to me that this would be a great place to put > a 'recoverable guru'... because a negative reference count > virtually assures the library will *never* be expunged anyway. Only if the library were programmed to trigger on a negative reference count and set an ignore expunge request flag. Under normal circumstances, if the reference count has gone to negative one, all it takes is two more opens and a single close and expunge request to make the library go away. However some program still will think it has it opened and the very next call it makes will result it a disaster. -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.