autoloading from deleted wordcode digest files

autoloading from deleted wordcode digest files

[Clint Adams]

I'm making .zwc files using zcompile -U -M.
zsh will keep these files opened and mmapped even
after they are deleted, but efforts to autoload
functions within will fail.

I want the deleted file to be searched if the function
is not found on disk.  I assume that this can be accomplished
by including the filename in struct funcdump, and using
that as an identifier should the files be deleted after
mmapping.

Will this break anything?

Re: autoloading from deleted wordcode digest files

[Sven Wischnowsky]

Clint Adams wrote:

> I'm making .zwc files using zcompile -U -M.
> zsh will keep these files opened and mmapped even
> after they are deleted, but efforts to autoload
> functions within will fail.
> 
> I want the deleted file to be searched if the function
> is not found on disk.  I assume that this can be accomplished
> by including the filename in struct funcdump, and using
> that as an identifier should the files be deleted after
> mmapping.

Somehow I think the OS should ensure that such files can't be deleted
(by renaming them as it does for the .nfs* files or something).

Hm, things could break terribly if mapped function files disappear and I
don't see a completely satisfying solution.  Searching again for the zwc
file works for functions that haven't been loaded yet, but what about
those that were used already?

> Will this break anything?

This certainly depends on how you write it ;-)  And probably on the way
the system handles all this.


My first reaction would be to print a warning, suggesting to re-start
the shell and mark the funcdump structure to not be used again.  But
that's only one step back from re-searching and -opening it, as you
suggest.

In short: hm, shrug, dunno.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: autoloading from deleted wordcode digest files

[Bart Schaefer]

On Jun 6, 11:47am, Sven Wischnowsky wrote:
} Subject: Re: autoloading from deleted wordcode digest files
}
} Clint Adams wrote:
} 
} > I'm making .zwc files using zcompile -U -M.
} > zsh will keep these files opened and mmapped even
} > after they are deleted, but efforts to autoload
} > functions within will fail.
} > 
} > I want the deleted file to be searched if the function
} > is not found on disk.  I assume that this can be accomplished
} > by including the filename in struct funcdump, and using
} > that as an identifier should the files be deleted after
} > mmapping.
} 
} Somehow I think the OS should ensure that such files can't be deleted
} (by renaming them as it does for the .nfs* files or something).

The OS does ensure that they're not deleted -- it keeps the inode around
but deletes the directory entry, just as for any other open file (cygwin
notwithstanding); but autoloading checks for the existence of the file by
name before using the already-mapped copy.  Clint wants zsh to remember
what name it used to map a file and then keep using that mapped copy even
after the name has gone away on disk.

} Hm, things could break terribly if mapped function files disappear and I
} don't see a completely satisfying solution.  Searching again for the zwc
} file works for functions that haven't been loaded yet, but what about
} those that were used already?

You have it backwards.  Clint wants check_dump_file() to search for a
function in the already-mapped files because load_dump_header() fails
if it can't do an open().

} > Will this break anything?
} 
} This certainly depends on how you write it ;-)  And probably on the way
} the system handles all this.

The problem I see with it is that it could cause mysterious violations
of fpath ordering.  I guess it wouldn't be so bad if it were only the
fallback case exactly when load_dump_header() can't open().

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: autoloading from deleted wordcode digest files

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> You have it backwards.  Clint wants check_dump_file() to search for a
> function in the already-mapped files because load_dump_header() fails
> if it can't do an open().

Ahem.  Yes, that makes more sense.

Note that check_dump_file() does search mapped files, but only if
try_dump_file() could stat the file to compare st_ino and st_dev.

I think I actually considered saving only the filename in the funcdump
struct and compare that (for the equality test, we'd still need
something like that to find out which is the youngest file).

So, to answer Clint's question: with a bit of tweaking on the tests done
I think this would be fine (so that the current behaviour is kept as far
as possible -- only changing what happens when the digest file is
removed).  And, no, I can't see anything that would break -- I'm not
quite sure how the time-stamp comparisons should work with a deleted
file, though, but that seems solvable.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: autoloading from deleted wordcode digest files

[Andrej Borsenkow]

            And, no, I can't see anything that would break -- I'm not
> quite sure how the time-stamp comparisons should work with a deleted
> file, though, but that seems solvable.
> 

Will this help?

int fstat(int fildes, struct stat *buf);

-andrej

Re: autoloading from deleted wordcode digest files

[Clint Adams]

On Wed, Jun 06, 2001 at 10:44:39AM +0000, Bart Schaefer wrote:
> You have it backwards.  Clint wants check_dump_file() to search for a
> function in the already-mapped files because load_dump_header() fails
> if it can't do an open().

Right.

> The problem I see with it is that it could cause mysterious violations
> of fpath ordering.  I guess it wouldn't be so bad if it were only the
> fallback case exactly when load_dump_header() can't open().

On Wed, Jun 06, 2001 at 01:14:18PM +0200, Sven Wischnowsky wrote:
> Note that check_dump_file() does search mapped files, but only if
> try_dump_file() could stat the file to compare st_ino and st_dev.

> I think I actually considered saving only the filename in the funcdump
> struct and compare that (for the equality test, we'd still need
> something like that to find out which is the youngest file).

On Wed, Jun 06, 2001 at 03:21:04PM +0400, Andrej Borsenkow wrote:
> Will this help?
> 
> int fstat(int fildes, struct stat *buf);

I suppose that would also obviate the need for storing the
filename in funcdump.