Path: utzoo!attcan!uunet!isc-br!jimc
From: jimc@isc-br.ISC-BR.COM (Jim Cathey)
Newsgroups: comp.sys.mac.programmer
Subject: Re: RAM serial driver and event handling
Message-ID: <2939@isc-br.ISC-BR.COM>
Date: 20 Sep 90 14:29:10 GMT
References: <1021.26f75aef@iccgcc.decnet.ab.com>
Organization: ISC-Bunker Ramo, An Olivetti Company
Lines: 29

In article <1021.26f75aef@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) writes:
>1) Is it a safe or sanctioned operation to use nullEvent to read any
>received data from the serial port?  What I need to do is allow event
>processing to continue while I am waiting for replies.  Something that
>might simplify this is that there are no unsolicited responses, so I
>know when to look for received data : only after I've sent some out.
>But while I am waiting for a reply packet, I want to continue to
>respond to user input.

Post an _asynchronous_ read to the serial driver, and have the
completion routine do whatever it can to finish processing the packet.
This could range all the way from just setting a flag (that you can
check on nullEvent) to completely handling the packet and posting other
reads/writes to the serial driver, assuming that this can all be done
with the usual interrupt level code restrictions (no traps that move
memory, etc).  This has the advantages that there is no hokey polling,
you don't have to patch anything, and you will never miss the packet
even if you're in another application/DA or the menu system, etc.  This is
why the async calls are available (for nearly everything except SCSI
disks, I think).  

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"