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.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
