On Thu, 17 Mar 2011 11:51:33 +0100 "Jesper Saxtorph" <jesper.saxto...@prevas.dk> said:
the problem is - you are BOTH right and BOTH things break something. suggestion. use things OTHEr than modified timestamp for comparisons. ie timestamp must EXACTLY match for caching (== not >=), ANd size, and mode, and uid and gid, inode... the filesystem may also support (on linux) nanosecond resolution: st_mtimensec (see bits/stat.h). thats the only kind of solution that will make everyone happy. still not 100% perfect as size may be the same and inode re-cycled, and other things the same (als the timestamp discussion) BUT if the fs supports nanosecond res timestamps... you are golden... well unless the file was written within the same nanosecond :) > I understand your thoughts, however I your suggestion will not work. I > will try to explain it clearer. Bear with me, if it gets a little long > and I repeat what is written earlier, but I am not sure what part you > are missing. > > In an ideal world where timestamps has infinite precision and they > represents the actual real time the files has been changed (never future > timestamps). If this was the case the original code would work fine. > > In the real world 3 things can happen to break the setup. > 1) People can force incorrect timestamps. > 2) By error files can be marked in the future. If this happens we risk > that the file will be changed again at the exact time of the timestamp, > which means 2 writes with the same timestamp. > 3) The file can be written more than one time with the same timestamp > because of the timestamp resolution. > > Case 1), we should not really care about, as people break the system on > purpose. > > For both case 2) and 3) the problem happen in the following situation: > a) Imlib reads the file and register the timestamp of the file (for > simplification I consider this atomic in this example). The file content > is cached. > b) The file is changed, but the timestamp is still the same. This can > happen according to case 2) and 3) above. > c) Imlib need the file data again and want > (imlib_image_set_changes_on_disk) to decide if the cached data is valid. > It checks the timestamp to validate this. However, as the timestamp has > not changed, the data are deemed valid, while in reality they are not. > > Now back to your suggestion. > What you do is the following: On first load you cache the data. On a > later load you try test if the files current timestamp is right now. > > So lets take an example of why can fail according to case 3): > I) A file is written at time 17. > II) The file is read and cached by imlib at time 17. > III) The file is changed again after the imlib read but still at time > 17. > IV) At time 20 imlib need the data again. It try to validate the cache. > However, since the cache timestamp is still equal to the file timestamp > and not equal to the current time (20), imlib will validate the cache, > which is wrong. > > You can make a similar scenario for case 2) > > I hope this makes it more clear. > > -Jesper > > ------------------------------------------------------------------------------ > 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 > -- ------------- 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
