home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaUtilCD2.iso / Misc / CBMDevKit1.dms / CBMDevKit1.adf / tutorials.lha / tutorials / NewDosPackets < prev    next >
Encoding:
Text File  |  1993-11-04  |  2.5 KB  |  57 lines
  1.  
  2.             New V39 DOS Packets
  3.                         ===================
  4.  
  5. ACTION_EXAMINE_ALL_END: takes the same arguments as EXAMINE_ALL, same returns
  6. (though it shouldn't indicate that there's more to do).
  7.  
  8. ACTION_SET_OWNER: same as ACTION_PROTECT, except the data is a longword of
  9. owner info: high 16 bits are GID (group), low 16 are UID (user id).
  10.  
  11. ACTION_SERIALIZE_DISK: Takes no parameters, makes the FS change the disk to
  12. make it unique (normally by changing the creation date).  Useful in
  13. diskcopy with non-amiga filesystems (diskcopy knows about amiga filesystems
  14. and can do it without the packet for them).  Normal sorts of return codes.
  15.  
  16. >- There is some confusion about ACTION_CURRENT_VOLUME.
  17. >  According to some docs this packet does not take any arguments
  18. >  and returns a BPTR to the _current_ volume node in Arg1.
  19. >  However years ago computer magazines reported that this information
  20. >  is incorrect, and that the packet takes fh->fh_Arg1 from a
  21. >  filehandle in Arg1 and returns the volume node _corresponding
  22. >  to that filehandle_ in Res1 and its exec unit number in Res2.
  23. >  I'd like to know who is right...
  24.  
  25.     In a way, both are correct.  If arg1 is NULL, that it returns the
  26. current volume and unit number.  If arg1 is fh_Arg1 of a filehandle, it
  27. returns the volume and unit for that filehandle.  Good find, I didn't realize
  28. that description was wrong (almost nothing uses ACTION_CURRENT_VOLUME, except
  29. some error reporting code in dos).
  30.  
  31. ******
  32.  
  33. >- From your experience with the Amiga filesystem: Assuming
  34. >  a process asynchronously sends two packets to the FS that
  35. >  refer to the same file, but have to be executed in sequence,
  36. >  e.g. two CMD_READ requests to the same file. A multithreaded
  37. >  FS might try to execute them in parallel. Is it necessary to
  38. >  serialize two packets that come from the same process within the
  39. >  FileSystem somehow, or are user processes just not expected to
  40. >  do "that kind of thing" ?
  41.  
  42.     It's quite necessary to serialize them.  Martin's (vertex's) async
  43. IO code does that, and has been made available to a lot of developers.
  44.  
  45.     You might even find it necessary (or at least a good idea) to
  46. serialize access via any one filehandle, and ignore the task part of it.
  47. It's rare for two processes to use one filehandle, and if they are, they're
  48. probably cooperating and may depend on ordering.
  49.  
  50.     BTW, the Amiga FS _is_ multithreaded...  Admittedly it's BCPL
  51. coroutine threading, but it is threaded.  Each filehandle has a separate
  52. coroutine to handle IO's for the FH, with a 1K stack.
  53.  
  54.     Randell
  55.  
  56.  
  57.