Path: utzoo!attcan!uunet!samsung!brutus.cs.uiuc.edu!psuvax1!husc6!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need info on multitasking capabilities on the mac
Message-ID: <17254@dartvax.Dartmouth.EDU>
Date: 25 Nov 89 21:27:59 GMT
References: <6391@tank.uchicago.edu> <9072@hoptoad.uucp> <17247@dartvax.Dartmouth.EDU> <9080@hoptoad.uucp>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 45

In article <9080@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <17247@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu
>(Earle R. Horton) writes:
>>I don't know, but won't an asynchronous read/write with an
>>ioCompletion routine installed work?
...
>I thought that MultiFinder would refuse to context switch if the file
>or device system had any pending asynchronous requests.  But maybe I'm
>thinking of an earlier incarnation.  It's fairly painful to write a
>complete protocol scheduled from completion routines, but it can be
>done.

According to TechNote 180, context switching can occur with pending
Device Manager calls, but not File Manager calls.  Furthermore, your
ioCompletion routine will get called when the Device Manager call has
completed, even if you are swapped out.  This looks like the obvious
place to implement a file transfer protocol that must have regular
periodic service.  No pain, no gain!

>
>>The protocols used by VersaTerm use handshaking on each packet.  You
>>don't get a new packet, in other words, until you acknowledge the last
>>one.  With these protocols, you can actually pause a fairly long time
>>between times when you service the file transfer.  I suspect that
>>VersaTerm doesn't do anything special to make sure it gets time, but
>>that you just never see it time out because you never push it that
>>hard.
>
>Um, not with XMODEM.  Most implementations will time out if they don't
>get an acknowledgement before the timeout period expires.  Doesn't
>VersaTerm use XMODEM?

VersaTerm uses three or four variations of XMODEM and also Kermit.
Yes, these will all time out after a certain period.  However, it is
possible to make a sender pause simply by waiting before you handshake
any packet.  The exact timeout period will vary, but in my experience
XMODEM and Kermit are quite forgiving and will wait a long time before
they give up on you.

I suspect that there are more problems implementing a streaming
protocol like ZMODEM properly, especially when doing downloads.  This
is simply because you cannot make the sender pause at fairly arbitrary
times as you can with one of the packetized protocols.

Earle R. Horton