Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!spdcc!merk!alliant!linus!mbunix!duncant
From: duncant@mbunix.mitre.org (Thomson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Help - Asynchronous I/O to/from files
Message-ID: <99866@linus.UUCP>
Date: 2 Mar 90 03:47:07 GMT
Sender: news@linus.UUCP
Organization: The MITRE Corp., Bedford, MA
Lines: 36

My original question was:
> How do I do asynchronous I/O to/from files?

Someone answered:
>
>Personally, I would have spawned a couple of tasks, which only used the upper
>level AmigaDOS routines--Open, Close, Read, Write, Lock, etc.  Then, throw in
>a few message ports to handle the I/O request "packets".  (In fact I did this
>for one of my courses last term, to demonstrate double buffered i/o--BTW, I
>wrote it in Modula-2.)

I thought that tasks could not access AmigaDOS routines without causing a 
guru?  (I don't remember where I read this, but I know that in the figures
of the Amiga software architecture in the front of the RKMs Exec is
shown below - used by, not using - AmigaDos.)  I know that it is possible to
spawn a coule of _processes_ which can then use the upper level AmigaDOS 
routines - but the problem here is that spawning a process requires a
call to LoadSeg - which does a disk access!  The whole point of double-buffering
is to speed up disk access by doing input, output, and processing in parallel.
If you have to do additional disk accesses to get your double-buffering
going, that kind of defeats the purpose.  Also, its a bit messy - since 
loadseg has to know the path of the load module its going to load - which
means you have to be sure that the files will always be in the right place
when the program is run.

Am I off track here?  Can tasks in fact call Read(), Write() and so on?  
Or can processes be spawned without having to do a disk access?

I was just getting set to launch into doing it by sending packets to
the filesystem handler - but if there is an easier way...

Thanks
Duncan Thomson (would-be Amiga ssytem programmer!)

--
(Please excuse the typos and garbage caused by line noise.)