[Pkg-octave-devel] Bug#550823: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())

[John W. Eaton]

On 20-Oct-2009, Søren Hauberg wrote:

| tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek:
| > The problem is in load_path::update, which checks the directory's
| > modification time to decide on whether to rescan it. The resolution is
| > only in seconds, though.

It is possible to get better resolution, but only for filesystems that
support it.  Currently, I'd guess that the most widely used filesystem
on Linux systems is probably ext3, and that only has one second
resolution for file time stamps.

| But some check is surely wanted because you
| > want to avoid useless rescans. I don't have a better idea. One could
| > even say this is a limitation of the system, which provides no way to
| > tell whether the directory has changed during the last second. Maybe
| > rehash() could ignore the stamp for some directories? But which ones?
| 
| Perhaps it would be better to use a notification system instead of
| checking for file changes? Specifically, I'm thinking that we should be
| able to use, say, 'inotify' to notify us that a file has changed. When
| such a notification is sent Octave could then re-read the file. This
| would probably also be faster than the current approach of scanning for
| file changes.

I agree that being notified of changes would be better than checking
timestamps, but I don't think there is any portable way to be notified
when a file changes.

If possible, I'd rather avoid solutions that only work on some
systems.

The symbol table code already includes the following:

  octave_value
  symbol_table::fcn_info::fcn_info_rep::find (const octave_value_list& args,
					      bool local_funcs)
  {
    octave_value retval = xfind (args, local_funcs);

    if (! retval.is_defined ())
      {
	// It is possible that the user created a file on the fly since
	// the last prompt or chdir, so try updating the load path and
	// searching again.

	load_path::update ();

	retval = xfind (args, local_funcs);
      }

    return retval;
  }

So if this is not sufficient, why not?  Is it because update always
checks the time stamp?  In that case, maybe we need to have a "force"
parameter to tell load_path::update to ignore the time stamp?  That
would make this update operation slow, but it would only happen when a
symbol is not found the first time around, so I wouldn't expect it to
be a big problem.

jwe