dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/10/86)
If I queue a write to the DOS handler for a specific file, then do some other operation normally (such as a Read() or Seek()), will the DOS handler do the write operation before the Read() or Seek() (e.g. in the order PutMsg'd to the port), or can things get mixed around? Thanks, -Matt
phillip@cbmvax.cbm.UUCP (Phillip Lindsay) (09/11/86)
> > If I queue a write to the DOS handler for a specific file, then do > some other operation normally (such as a Read() or Seek()), will the DOS > handler do the write operation before the Read() or Seek() (e.g. in the > order PutMsg'd to the port), or can things get mixed around? > > Thanks, > > -Matt The requests are handled in a "fifo" fashion. So yes, if you queue a write then a read ... the write will be done first. -- ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support Dirt: 1200 Wilson Drive, West Chester PA 19380 uucp: {ihnp4|seismo|caip}!cbmvax!phillip arpa: cbmvax!phillip@seismo -or- phillip@cbmvax.UUCP@{seismo | harvard} Tel.: (215) 431-9180 Disclaimer: [someone said I needed this] No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. [unless Fred pops up (my other self)] ==============================================================================
phillip@cbmvax.cbm.UUCP (Phillip Lindsay) (09/12/86)
> > > > If I queue a write to the DOS handler for a specific file, then do > > some other operation normally (such as a Read() or Seek()), will the DOS > > handler do the write operation before the Read() or Seek() (e.g. in the > > order PutMsg'd to the port), or can things get mixed around? > > > > Thanks, > > > > -Matt > > The requests are handled in a "fifo" fashion. So yes, if you queue a write > then a read ... the write will be done first. > -- From Neil Katin: "The user cannot have more than one packet outstanding to an individual handler at once. This is especially true for things like CON:, SER:, etc." "For the file system, one can only have one packet per open file handle." -- ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support Dirt: 1200 Wilson Drive, West Chester PA 19380 uucp: {ihnp4|seismo|caip}!cbmvax!phillip arpa: cbmvax!phillip@seismo -or- phillip@cbmvax.UUCP@{seismo | harvard} Tel.: (215) 431-9180 Disclaimer: [someone said I needed this] No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. [unless Fred pops up (my other self)] ==============================================================================
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/15/86)
>From Phillip Lindsay >\From Neil Katin: > >"The user cannot have more than one packet outstanding to an individual > handler at once. This is especially true for things like CON:, SER:, > etc." > > "For the file system, one can only have one packet per open file > handle." Earlier versions of my asyncronous write addition to my XSTDIO library crashed, and they just happened to be queuing more than one packet on the handler's port. Now I know why, but it would be interesting if someone at amiga would comment as to why this restriction exists. However, it does NOT mean asyncronous I/O can't be done. As soon as I make sure my library adhears to these restrictions, I'll post it. Consider the following senerio: -Queue a 40K write to some file on df1: -While that write is taking place attempt to read from some file on df0: I tested this sort of thing by modifying the source to 'backup' slightly to use the new async-feature. However, it was only a mere 3% faster. This is due to the fact that both handlers must ultimately share the disk-bus for DF0: and DF1:... I think much better results would occur if you were going between a DFx: and an HDx:, or from DFx: to SER: (or something like that). I think, however, that you modem-program writers will like the feature for your 'capture' mode... since writes happen infrequently, making the asyncronous is a real boon because it virtually eliminates the delay you normally see when the thing goes to disk. This time I'll include the documentation, but post the library uuencoded (so you don't have to compile it all). If you want the source just mail me and I'll send it to you. -Matt