Mail Archives: djgpp-workers/2001/09/24/13:06:16
> Another possibility is to add to `_close' or to `close' code which
> will walk FILE objects and if it finds one that uses the handle being
> closed, it will mark that FILE object as unused, like `fclose' does.
> The disadvantage of this is that it slows down `_close'/`close', and
> doesn't catch code which closes the handle via `__dpmi_int' or
> `int86'.
This seems reasonable since we just scan our file structures (no
interrupts). Closing with direct interrupts should be rare. It
fixes the problems and is probably the fastest solution. Could we
leave the FILE object used but just set the handle to -1, just in
case the user re-uses the FILE object? I'm not worried about the
small memory loss in this rare situation.
> Yet another possibility would be to modify `__alloc_file' to test the
> handle in each FILE object when it looks for an empty slot: if the
> handle is invalid, it could consider the FILE object unused, even if
> its flags say otherwise, and reuse that slot. To see if the handle is
> invalid, we could lseek(fd, SEEK_CUR, 0L), for example.
This also seems reasonable, but I would rather use some of the fd_props
structures to try and do this instead of a bunch of new interrupts
which might break something. If we had to lseek I would choose the
close() option above. We can do several thousand operations internally
for the cost of one interrupt.
What about having a back link pointer in the fd_props to file structure?
If it's used then close() would not need to scan?
- Raw text -