On Thu, 10 Mar 2011 10:31:32 +0100, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Sun, 06 Mar 2011 07:49:59 +0100 "Kim Woelders" <k...@woelders.dk> said: > >> On Thu, 03 Mar 2011 15:46:15 +0100, Jesper Saxtorph >> <jesper.saxto...@prevas.dk> wrote: >> >> > I have just submitted a bugraport + a patch on trac (bug #716). >> > >> > I just wanted to notifify it here also as I do not know the >> > enlightenment community and how it works. >> > >> Either is fine. >> >> > To repeat my bug report: >> > "I use imlib2 as a image library in a project. However the use we have >> > sometimes tricker a situation where imlib2 uses an invalid cache. >> > >> > imlib2 uses timestamps to test if a image cache i valid. If a files >> > modification time is in the future it is not possible to use >> validation >> > scheme. Further if the timestamp is equal to now, we do not know if >> the >> > modification time is in the future or not. The result is that the >> cache >> > should be invalidated for file timestamps >= now. >> > An example of a problematic situation: timestamps are in whole seconds >> > times given as here as seconds: >> > time=32.1 : image.png is written by someone >> > time=32.4 : image.png is loaded by imlib2 >> > time=32.5 : image.png is written with new data >> > The situation is now that the cache has the same timestamp as the >> file, >> > but the content is not the same. >> > >> > A possible fix is a 3 line patch, which I have attached. It invalidate >> > the cache if the files timestamp is >= now. >> > The patch is made agains head, however, the image.c file (where the >> > patch is applied) has changed very little in it lifetime, so it works >> > fine with earlier versions of imlib2 (I use it against 1.4.2)." >> > >> > I attached an incorrect patch at first to the ticket, but have >> submittet >> > the correct afterwards. Sorry for that. >> > >> > My suggestion to a patch (I have made the long comment as I think it >> is >> > not obvious why it is needed): >> > --- imlib2/src/lib/image.c.orig 2011-03-03 14:23:49.000000000 +0100 >> > +++ imlib2/src/lib/image.c 2011-03-03 14:45:19.000000000 +0100 >> > @@ -1017,6 +1017,18 @@ >> > im->key = __imlib_FileKey(file); >> > } >> > im->moddate = __imlib_FileModDate(file); >> > + /* If the file modify time is now or in the future, we can not >> make >> > a */ >> > + /* cache. */ >> > + /* One of several possible scenarios: */ >> > + /* time=now: file is written by someone */ >> > + /* time=now: file is loaded here */ >> > + /* time=now: file is written again by someone */ >> > + /* Now we have a file a timestamp equal to our cache, but with a >> */ >> > + /* different content. */ >> > + if (im->moddate >= time(NULL)) >> > + { >> > + dont_cache = 1; >> > + } >> > /* ok - just check all our loaders are up to date */ >> > __imlib_RescanLoaders(); >> > /* take a guess by extension on the best loader to use */ >> > >> > Hope it make sense, otherwise feel free to ask and/or discuss it >> > >> I see there is a problem, but I don't think it is the proper solution. >> If you have a file with a "now"/future time stamp it would never be >> cached, which is wrong. >> >> How about in stead changing line 986 (svn) to check whether the time >> stamp >> has changed in stead of checking if it is newer? > > while in general you are also right.. he's also trying to fix the > problem of > "write file at 34.1 secs, then write AGAIN at 34.5 secs" - they both > have the > SAME timestamp but the 2nd is newer. imlib2 will not load the newer file > as the > timestamps match due to timestamp resolution (34 vs 34 secs). but while > solving > this problem it breaks caching for timestamp == now. you'd need much > higher > resolution timestamps (and even then you still just have a smaller race > condition) or .. you'd have to have another way to differentiate the > files. > file size + timestamp + inode + .... even then you just lower the > probability > not eliminate it. > Yeah, I know. The important thing here, IMO, is that images which never change, should always be cached (unless explicitly not caching), whichever past/now/future time stamp they may have. How about this: diff --git src/lib/image.c src/lib/image.c index d404961..e8610b2 100644 --- src/lib/image.c +++ src/lib/image.c @@ -982,8 +982,10 @@ __imlib_LoadImage(const char *file, ImlibProgressFunction progres time_t current_modified_time; current_modified_time = __imlib_FileModDate(file); - /* if the file on disk is newer than the cached one */ - if (current_modified_time > im->moddate) + /* if the disk file time stamp is different from the */ + /* cached one or appears to have just been set */ + if ((current_modified_time != im->moddate) || + (current_modified_time == time(NULL))) { /* invalidate image */ SET_FLAG(im->flags, F_INVALID); This of course requires using imlib_image_set_changes_on_disk() in the application. /Kim ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel