kevin@mermaid.Litle.Com (kevin p burke) (11/03/90)
am I clueless or does the mac have no non blocking io? I'm writing some code and don't want to hang around in reads and getlines for ever. even poll would be nice. I've tried to RTFM and not yet found such a feature. Could some one be a kind soul and point me in the right direction? thanx -k -- Kevin P. Burke, SysAdm/Postmaster, Litle & Co | POB C26, Hanover, NH 03755-6000 ------------------------------------------------------------------------------- "Just Do It." | +1 603 643 1832/1834 ------------------------------------------------------------------------------- kevin@mermaid.litle.com {backbone}!dartvax!mermaid!kevin
u-lchoqu%peruvian.utah.edu@cs.utah.edu (Lee Choquette) (11/03/90)
In article <520@mermaid.Litle.Com> kevin@mermaid.Litle.Com (Kevin P. Burke) writes: Am I clueless or does the Mac have no non blocking io? I'm writing some code and don't want to hang around in reads and getlines for ever. Even poll would be nice.... Use the low-level File Manager routines described in Inside Mac II-97-114. You'll have to pass in a parameter block to each routine, and specify asynchronous calling, as in error = PBRead (pBlock, TRUE); If you want to poll, set pBlock.ioCompletion = NULL and poll pBlock.ioResult, waiting until ioResult != 1. Or you can make pBlock.ioCompletion point at a function you want called upon completion of the I/O request, but you must follow the restrictions on page 99 of what routines called at interrupt level may and may not do. The functional difference between this technique and Unix non-blocking I/O, is that in Unix if you get the error EWOULDBLOCK you don't necessarily have to go back later and read from the file. On the Mac you have a pending I/O request, and I can't find in Inside Mac a safe way to cancel that request. Does anyone out there know how to cancel an asynchronous File Manager request? What happens if your application quits before the request completes? Lee Choquette Internet: u-lchoqu@peruvian.utah.edu 3846 Barbara Wy Bitnet: choquette@utahcca Salt Lake City, UT 84124 UUCP: utah-cs!peruvian!u-lchoqu
chrisj@netcom.UUCP (Christopher T. Jewell) (11/05/90)
In article <1990Nov2.194118.29698@hellgate.utah.edu> u-lchoqu%peruvian.utah.edu@cs.utah.edu (Lee Choquette) writes: >On the Mac >you have a pending I/O request, and I can't find in Inside Mac a safe >way to cancel that request. Does anyone out there know how to cancel >an asynchronous File Manager request? What happens if your >application quits before the request completes? On the Mac, asynchronous requests really only make sense with devices, not with files. The high-level call KillIO (IM II-179) or the low-level call PBKillIO (II-187) will cancel all outstanding asynchronous requests to the specified device driver. -- Chris (Christopher T. Jewell) chrisj@netcom.uucp apple!netcom!chrisj at work: chrisj@lucid.com (I speak only for me, of course.)
urlichs@smurf.sub.org (Matthias Urlichs) (11/07/90)
In comp.sys.mac.programmer, article <16205@netcom.UUCP>, chrisj@netcom.UUCP (Christopher T. Jewell) writes: < In article <1990Nov2.194118.29698@hellgate.utah.edu> u-lchoqu%peruvian.utah.edu@cs.utah.edu (Lee Choquette) writes: < >On the Mac < >you have a pending I/O request, and I can't find in Inside Mac a safe < >way to cancel that request. Does anyone out there know how to cancel < >an asynchronous File Manager request? What happens if your < >application quits before the request completes? < < On the Mac, asynchronous requests really only make sense with devices, < not with files. Why not ? With floppy disks or AppleShare this makes perfect sense if you're willing to add a little bit of complexity to your program (i.e. let the user continue to look at his/her menus while your big file finishes loading). I admit that it doesn't make sense with SCSI disks, but only because the underlying block-level driver can't support async requests -- the MacOS SCSI "Manager" sees to that. :-( :-( The reason why you can't abort file manager requests is probably that it won't make much sense. What is the result of aborting a PBDelete()? You only delete half of the file? ;-) Seriously, the internal complexity of the file manager is amazing (at least from the point of view of someone who doesn't have access to the source code) and it seems that the almost-never-needed ability to cancel requests would have added yet another layer of complexity, and of bugs. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/