Re: sqlite3

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes, that would explain what we're seeing.  Is there any chance the w32
>> stat emulation could be fixed to support sub-second resolutions like it
>> does on other systems?
>
> It could, but it's not a trivial job, and doing it just for this use
> case could be overkill.

Well, it wouldn't be just for this.  Sub-second file resolution is
generally useful.

>> If not, I think we'll have to change how the values are stored, and add
>> a "header" section in the files themselves, so you'd have
>
> I think this is a good idea anyway.  Because we could have fast
> machines and disks that defeat even the best time resolution.
>
>> ---
>> Timestamp: <high res timestamp>
>
> Do we really need time?  That could fail due to clock skew, if the
> values are modified from different machines.  Wouldn't just a single
> "generation number", that keeps only increasing, be enough?

That would also be fine -- it's what we're using on the sqlite backend
in multisession.

But I'm not very enthusiastic about having a synchronised multisession
variable access reading and parsing a file each time, so I'm leaning
towards just keeping the code as is and adjusting the test on Windows
(and other systems that don't have sub-second resolution).  Synchronised
multisession variables offer no guarantees -- having two Emacsen
updating the variable at the same time is inherently racy, and we're
doing a best effort kind of thing.

So this will be slightly less spiffy on Windows, and that's fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no