Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Library Opens/Closes (was IEEE libraries) Message-ID: <8809250355.AA24098@cory.Berkeley.EDU> Date: 25 Sep 88 03:55:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 36 :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