Path: utzoo!attcan!uunet!tank!eecae!mailrus!ames!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: <6325@cbmvax.UUCP> Date: 17 Mar 89 20:44:30 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> <12361@microsoft.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Distribution: comp Organization: Commodore Technology, West Chester, PA Lines: 41 In article <12361@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >jesup@cbmvax.UUCP (Randell Jesup) wrote: >This isn't that hard to enlarge, but you want to get rid of the restriction >completely. Arrgh! If someone would give me a complete spec for dos.library >(basically, a list of BCPL kludges that need supporting), I could give you a >rewrite in a month. The silly thing doesn't *do* dick all. It does lots you don't see. dos.library is a small part of it. >> Two non-BCPL programs can right now. BCPL programs use the buffering >> fields in the file-handle, and would clash over them. > >You have to handle the reference-counting manually, but you can have multiple >processes all sharing the same filehandle without problems. The BCPL stuff >is disgusting, and I hope it gets fixed in 1.4, 'cause owing to a lack >of documentation, my FS is going to ignore that completely. If someone >tries to jump through one of those fields, boom! An FS is not allowed to even look at the fields of a filehandle other than the value it stores in fh_Arg1 (or some such name) that is passed back on read/write calls. The rest of the filehandle is private to dos/application. BCPL applications use the fields in there to do IO buffering, which is why they break if they try to share a filehandle. >But there's no way a handler can tell that two processes talking to >it over the same filehandle aren't really one, that just has a >strange prediliction for asynchronous I/O using multiple return >message ports. Actually the killer is where you are in the file. Also, who closes it? >(BTW, does anyone know what AN_AsyncPkt is caused by? Who sends an >unexpected packet to whom?) dos.library. If it gets a message at pr_MsgPort, and it's not the packet it sent out to do a file operation coming back, it gurus with AN_AsynchPacket. Typical mistake is to try to use any dos.library functions that send packets from a handler for debugs (or anything else). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup