NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/programm/16137

Text File | 1992-11-20 | 5.4 KB | 113 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!stanford.edu!rock!concert!samba!usenet
From: [e-mail] (Todd M. Lewis)
Subject: Re: Subtasks, IEEE library pointers - y.a.Q
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: guitar.oit.unc.edu
Organization: UNC Office of Information Technology
References: <[e-mail]>
Date: Fri, 20 Nov 1992 15:27:34 GMT
Lines: 100

In article <[e-mail]> [e-mail] (Craig Denson)
writes:
>In article <[e-mail]> [e-mail] (Todd
M. Lewis) writes:
>
  [ If I open the same library twice and the library pointers returned
    by OpenLibrary() are not equal, then ... ]
>>...  I've got different library
>>bases and there is no reasonable way to write subtasks that handle
>>that..
>
>  this is where i lose the thread.

OpenLibrary() is documented as returning a pointer to a Library (or NULL
on failure).  What it doesn't say, but happens with some, perhaps many,
libraries, is that in the process of opening, the library can inflict
whatever side effects it deems fit on the opening task/process.  That
in itself is not a problem as long as the effects are well-documented
and are guaranteed not to change in later versions of the library.  So
to be safe (and for the aesthetics of good design) every task that
uses a library should explicitly open and close each library it uses.
So far so good.

Your next series of questions hit practically every point I have been
trying in vein to make on this issue.  Let me take them one at a time.

>  What is in these libraries that must be the same?

Libraries are supposed to be black boxes, so the answer is supposed
to be "I don't know and I don't need to know."

> If it's a copy of the same code at a different
> location why should you care? are the bits a different color? :-)

I cannot know that it's the same code.  I (you) can only know the
location.  When one part of your program (the main task, say) has
to reference the library through the same base variable that other
parts (subtask 1-99) have to use and each one needs that variable to
point at a different place, there is no practical way that I know of
to handle it with the current tools available.  It isn't even pretty
in assembler, much less C etc.

Note that with the new SAS C compiler you can easily create libraries
which return a different base pointer each time they are opened, so
the question of how subtasks handle different pointers to the same
libraries is real, not just an academic question.

>  what's in the libraries that isn't relocatable?

Again, you have no way of knowing.  I didn't write these libraries,
these issues apply to any library that works in anything other than
the "obvious" way.  You aren't supposed to have to know.

>  or are you using library data as part of your application's data structure?
>  - that doesn't sound too good.

NAIL ON THE HEAD!  Give that man a banana.  Libraries are free to use your
application's data structure (the task/process structure and who
knows what else) in any way they want, and you can only hope they
document what they are doing and that they don't change strategies on
you in the next release (after you've got code running on customers
machines that follows the rules for the current release) and that
their side effects don't conflict with those of other libraries you
need to use.  I agree with you 100%, "that doesn't sound too good."

We've screwed this up once in a big way, and it would be nice to avoid
the mistake in the future.  Take two of the most popular libraries on the
Amiga: graphics.library and DOS library.  One did it right, the other
has the problem you so succinctly described--using library data as part
of [the] application's data structure.  The DOS process information
should not be so tightly coupled to the task structure.

Imagine how screwed up things would be if instead the RastPort was
coupled with the task struct and the process struct was stand-alone
like the RastPort is now. A task could open the DOS library and "own" as
many processes as it needed--you could have one "current directory"
on df0: and another on "dh0:", and lots of the problems with using DOS
today simply disappear. The catch is that with one RastPort so tied
to the task struct you could only draw to one RastPort at a time.  Need to
draw somewhere else?  "oldRast = CurrentRast(NewRast)" would solve
the problem.  Ridiculous you say, but that is exactly what we do now
with DOS and nobody even sees the problem.  The root of the problem isn't
that DOS is badly designed, but that it is needlessly and too closely
coupled to the task struct.

In the context of this discussion, the lesson above should point out
that writing libraries which impose such tight coupling with their
opening tasks on an ad hoc basis is open invitation to
incompatibility.  My big beef is the multiple subtask problem, but
that's just because I've been doing a lot with subtasks lately.  The
beauty of the Amiga's shared library is that it is a black box that any
program can use.  Now we have groups of libraries which, because of
these side effects, cannot be used by one program at the same time.

>craig
---
     Todd M. Lewis / [e-mail] / [e-mail]
 Another Month Ends / All Targets Met / All Systems Working / All Customers
Satisfied / All Staff Eager and Enthusiastic / All Pigs Fed and Ready to Fly