Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Proposal for new DOS calls
Message-ID: <8811082053.AA26882@postgres.Berkeley.EDU>
Date: 8 Nov 88 20:53:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 40

>In article <8811072046.AA04999@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>> 	There are several lackings in DOS that make interactive handling of
>> file handles difficult.  For one, there is no way to determine whether data
>> is pending (e.g. via SER: AUX:, interactive PIPE: etc...) without calling
>> Read() or WaitForChar().  Neither of these methods are acceptable as
>> both will block or require busy waiting.  

Peter da Silva  `-_-'  peter@sugar.uu.net Writes:
>What about the third method? Don't use the standard DOS calls, just send the
>packets yourself. Then you can "Wait(1<<IOPort->mp_SigBit | WaitMask)" and
>get a notice of completion when it's done.
...
>Be a lot simpler than your set of packets. Surely you can prune them somewhat.

	I disagree ... I've tried that method.  It is not compatible and
it doesn't work.  For one, you cannot make more then one DOS call pending
at a time, so between sending the packet and waiting for the reply you
can't make any DOS calls.  Now, I suppose you CAN make it go to a different
replyport, but a second problem exists:  You can't have more than one 
pending packet for a given file handle for a given process.  Reason:
Many device drivers can't handle it.  Specifically, the filesystem. 
Finally, you have to keep track of ports and messages and pending messages
and possibly other resources and free them yourself... they are far removed
from the DOS domain because they do not go away automatically with Close().

>Be a lot simpler than your set of packets. Surely you can prune them somewhat.

	Doing things manually gives you less control and certainly
is not simple in any sense of the word!  Very much more difficult, I would
say!
	One need not implement ALL the calls I proposed.  The basic three 
(capabilities, signal when read data present, signal when able to write) are 
usually sufficient.  Most of the others, except ShutDown(), are more
specialized.  ShutDown() *IS* a definate must when two interactive processes
communicate, sort of like saying "OK, I'm done sending stuff to you, 
finish up what you intend to send to me and then we'll close" rather than
"Close() = OK, I'm done sending stuff to you and I don't give a damn if
you still have stuff to send to me".  

				-Matt