Mail Archives: djgpp/1999/06/16/11:29:51
On Mon, 14 Jun 1999, Christopher Nelson wrote:
> Unfortunately, instead of getting re-used, =
> closed file handles are discarded. That means that a user may open only =
> 255-13 files in a session (not simulataneously, i mean ever. during the =
> life of the program, the user may only open a ramdrv file 255-13 times. =
> which means that you could open and close the same file 255-13 times, or =
> something similiar, see?) and after that it dies because I get a -1 for =
> the file descriptor.
>
> I realize that that happens because __FSEXT_alloc_fd only does a dup =
> off the descriptor for the "nul" device, but isn't there anyway to reuse =
> it?
There seems to be a misunderstanding here. You seem to assume that a
handle that is created by a call to `dup' cannot be closed with a call
to `close' because it didn't come from `open', right?
If so, this is simply incorrect: a handle that's created by `dup' is a
normal handle, and you can (and should) close it when it is no more of
use to your application. Closing such a handle will only free that
handle (and make it available for future reuse), and will not affect
any other handles, even though they all share the same NUL device.
DOS maintains a reference count in its internal data structure (called
"SFT") where it holds information about open files and devices, and it
will not close the file/device until the use count goes all the way
down to zero.
FSEXT doesn't do it for you because there's no way for the FSEXT code
to know when it is appropriate to free the handle. In fact, it
doesn't even know that closing it is the right thing to do, since it
has no idea what kind of functionality you emulate.
So the solution to this problem is to simply add a call to `close'
inside your close handler (of course, you should make sure that, when
you do that, FSEXT machinery doesn't call you again, or else your code
will catch the infinite recursion desease and die).
- Raw text -