2009/10/20 Thomas Weber <thomas.weber.m...@gmail.com>: > Hi, > > On Thu, Oct 15, 2009 at 02:09:30PM +0000, Sébastien Villemot wrote: >> Hi, >> >> I think I found the culprit for what I thought was a race condition in >> Octave. >> >> The problem has to do with the way Octave 3.2 updates its load-path: it >> only updates its cache of the current directory if the modification time >> of the directory changes (see load_path::dir_info::update() in >> src/load-path.cc). > > In case it's not clear: this is a real problem and not some artificially > found issue. It makes software using Octave randomly fail at build time. > > Thomas >
I don't understand - what you mean by "build time"? Most software using Octave is not dynamically creating m-files, so is not affected. 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. 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? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
