|Re: [hatari-devel] Fforce() fails with GEMDOS drive emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Thu, 14 Mar 2013 12:20:16 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> (Moving the technical discussion from users to devel where everybody
> On keskiviikko 13 maaliskuu 2013, Eero Tamminen wrote:
> > On keskiviikko 13 maaliskuu 2013, Eero Tamminen wrote:
> > > Redirecting the handle is easy, but when Hatari should stop
> > > redirecting it?
> > >
> > > When program calls something else (what?)?
> > On Fclose() redirection should be removed. This is easy.
> > Attached patch adds that and Fforce() emulation. However...
> > > When the program exits (=must hook also Pterm())?
> > ..this is much trickier. I noticed that Hatari doesn't
> > close *any* file handles when program terminates.
> > I.e. if one runs in a row a large number of programs that open
> > many files, but which don't close them before exiting, Hatari
> > GEMDOS emulation will run out of internal file handles.
> > I could add a hook for Pterm(), Pterm0() and Ptermres()
> > that will close files and unalias them, but which of the open
> > emulated files should be closed/unaliased on program exit?
> > How Hatari could know that given file is for current program
> > and not for a program that started it?
> > And what should happen if program crashes instead of
> > terminating normally?
> I was thinking that I could track program startup and termination,
> keep counter for current program  and use that to identify which
> file handles belong to which program & are valid for it.
> However, reliably detecting progam startup and termination so
> that they don't get out of sync, is quite tricky, so I need some
IIRC there is an official method for determine the current running
GEMDOS process - the "p_run" system variable. Hatari already keeps a
pointer to its location in the "act_pd" variable. So you could try to
find out the corresponding process via that variable?