Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!brutus.cs.uiuc.edu!usc!snorkelwacker!mit-eddie!uw-beaver!ubc-cs!cheddar.cc.ubc.ca!panon
From: panon@cheddar.cc.ubc.ca (Paul-Andre Panon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: resource tracking
Message-ID: <6948@ubc-cs.UUCP>
Date: 1 Mar 90 02:55:43 GMT
References: <1165@lpami.wimsey.bc.ca>
Sender: news@cs.ubc.ca
Reply-To: panon@cheddar.cc.ubc.ca (Paul-Andre Panon)
Organization: UBC Computing Centre, Vancouver, B.C., Canada
Lines: 63

In article <1165@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>Rather depends on what you mean by a system call and IPC doesn't it? The
>programmer need not concern himself that IPC is happening as the result of a
>system call, nor does he need to handle messages just because the system is
>using them behind his back.
>
>>IPC is integral to the Amiga. Sharing memory between a bunch of tasks is not
>>something you can get away from. It's rare on UNIX.
>
>That I'll go along with.
>
>-larry

I think you lost the context of the thread, Larry. The idea was that, for most
system calls on the Amiga, one or more messages will wind up being passed
somewhere in the processing of that call. This is certainly true in the case
of most filesystem or device I/O. Which means that, unlike what was stated
in another message by somebody else (Peter?) a CLI doesn't qualify. It uses
dos's CON: handler, thus the console.device, IDCMP messages, and at the lowest
level, input.device. Probably most of these will generate messages when the
device process has "locked" device globals (although the code may be executed
in the calling process' context occasionally; if the RKM:L&D device format
is the used in the device, BeginIO only generates a message to the device
process to queue the command if another command is already in progress). To
guarantee that you would do no message passing, you would probably have to:

          -Bypass intuition by building your own View and use the layers
  library (optional if you don't want windows) and the graphics library for
  output,
          - I'm not sure whether you could do input without at least one
call/message to the input.device to shut it down so you can take over,
          - NOT do any "file" I/O, not even trackdisk.device!

    Now, the first condition is generally pretty amiga unfriendly. Maybe
you wouldn't have to go quite so far if OpenScreen() doesn't actually send
a message - this is probably the case since it probably does stuff by
locking IBase; you could then do output into the screen's rastport and
even use layers without IPC. However, I seem to remember from stuff posted
here that the structure of intuition is one of the things which undergoes
major changes in 1.4 so it may be impossible to OpenScreen() without using
IPC under 1.4.

    Limiting your program to doing output kind of cuts down on the classes of
program you can have.

    Interestingly enough, most arcade-type game programs can meet those
requirements (once loaded) since I've gotten the impression you can get input
from the second port in an "amiga-friendly" manner without going through the
input.device, ie. at the resource level. It wouldn't be very clean though,
would it?

    So you probably can get a fair amount done without IPC on the Amiga if you
go to a sufficiently low level, but most of the higher level libraries do use
IPC. You would lose most of the Amiga's UI capabilities if you limited yourself
to non-IPC functions. This, I, think is probably what the original author had in
mind when this thread started and he said (paraphrased) that most Amiga function
calls used IPC.

--
      Paul-Andre_Panon@cheddar.cc.ubc.ca      or      USERPAP1@UBCMTSG 
or    Paul-Andre_Panon@undergrad.cs.ubc.ca    or      USERPAP1@mtsg.ubc.ca
"What should the role of the University be? It should be to enlighten Society."
  -Luis Sobrino