onn@utcs.uucp (Brian Onn) (11/17/85)
/* line eaters unite! */
I have (or may have) a problem that I was hoping someone knowledgable
could help me out with. This is the situation:
I am writing a program (80% complete) that will read data from the com port
and write it to a circular buffer, under interrupt control. The program
and buffer are made resident via INT 27. I have a second program (also
resident) that reads data from the buffer (the buffer is now a pipe) and
will eventually write it out to disk. The data in the buffer (pipe) contains
info as to drive, filename, etc.
This second program runs as a background process under the control of a
simple scheduler allocating 20% of the CPU to the background process. Now,
here's the problem: since the filename that the text is to be stored under
may contain path information, I have decided to use file handles to access
the file. Obviously, the background process will have to create the file
using an appropriate DOS function, opening it for writing. Since the process
gets only 20% CPU, it is likely that file I/O will not complete in that time,
and even more likely that there will be a buffer (DTA??) lying around with
unwritten data in it. So, what I am asking is this: does DOS use a separate
DTA for each open file handle?? (ie, since the file buffers are really a part
of each process' context, then they should be totally independant or
saved/restored for each context switch. Is this so?? What I am worried
about is having the background process get CPU, do a write call using the
file handle it got from a previous open, and trash an incomplete disk I/O
operation that had been buffered in a foreground process, now stopped. Or
vice versa.
Any help would be appreciated. Also, please, no lectures on DOS and
re-entrant code, etc. I have already compensated for that in the
background process. It will give up it's time slice if a dos call
was active when it got the CPU (ie it will not call dos again).
Please forgive me for the length of this posting, but I felt a little
background information was necessary, no pun intended.
Thanks,
Brian.
--
-----
Brian A. Onn
University of Toronto Computing Services
Erindale College.
..!{ihnp4,decvax,harpo,utcsri,{allegra,linus}!utzoo}!utcs!onn