Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!abvax!calvin!set
From: set@calvin
Newsgroups: comp.sys.amiga.tech
Subject: Library Opens/Closes (was IEEE libraries)
Message-ID: <435@abvax.UUCP>
Date: 17 Sep 88 01:09:32 GMT
Sender: news@abvax.UUCP
Reply-To: set@calvin ()
Distribution: na
Organization: Allen-Bradley Company, Inc.; Industrial Computer Division; Highland Hts. OH
Lines: 56


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