From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re:  Multithreaded code using CreateTask()
Organization: UNC Office of Information Technology
Date: Thu, 8 Oct 1992 21:23:29 GMT

In article <heinz.03ws@edohwg.adsp.sub.org> heinz@edohwg.adsp.sub.org (Heinz  
Wrobel) writes:
>If people use libraries without reading the docs it's ok that things break.
>You don't need a new OS call just because somebody is too lazy too document
>certain things or somebody else is too lazy to read those docs ;^)

The library mechanism is well documented and it is well-understood.
Nothing about the spec restricts cooperating tasks from sharing a base
pointer, and lots of popular programs have been doing it for years.

Then along comes something that looks like a library, smells like a
library, walks and talks like a library, and OpenLibrary() will even
open it up, but guess what--IT ISN'T A LIBRARY.  It has imposed the
additional restriction of requiring per-task state information. 
The system already has a nice place for such things.  They are called
devices.  And devices support functions just the same way as
libraries.  If you are creating a set of shared routines but you need
caller-specific state information, you could make your routines
into a device instead of a library.

If you still don't like that, you could create the equivalent of the
graphics library's RastPort--a node of caller-specific state
information.  (If you really want to muck around with fields in the
Task structure you are asking for trouble as no method has been
specified from On High on how to arbitrate access to those fields.) 

Libraries are there for the programmer's convenience.  They should be
written with that in mind--"How can we make this library as flexible
as possible" rather than "If the programmer doesn't heed all these new
restrictions we've come up with that no other library in the world has
required then he deserves to break."

If a library really needs to, say, fix up the trap vectors in the Task
structure then it should have a calls like imxulFixTaskVectors()
and imxulRestoreTaskVectors().  OpenLibrary() isn't documented
as having side effects on tasks and processes like having their
vectors messed around with, and the programmer may well have reasons
for not wanting it do that sort of thing.  I would hope that the Amiga
systems people would try to avoid endorsing adding side effects to
system calls that have been in the field for years.  Let's not go giving
OpenLibrary() the liberty to do whatever the heck somebody thought
would save them some work when writing a library.  There are ways to
handle per-task information, and OpenLibrary() is NOT one of them.   

I guess what really steams me about all this is that the Amiga has a
really clean software architecture.  You start letting little
restrictions like this creep in all over the place and you'll wake up
one day and find it isn't fun to program anymore--it'll become just
another software platform with a bunch of ugly restrictive warts. 
The polish will turn dim.  I want to keep it shiny as long as possible. 
--
    Todd M. Lewis / Todd_Lewis@unc.edu / utoddl@guitar.oit.unc.edu
"It isn't pollution that's harming the environment.  It's the impurities
 in our air and water that are doing it."  -- Vice President Dan Quayle
Newsgroups: comp.sys.amiga.programmer