Re: Defaults being destroyed

[Richard Frith-Macdonald]

On Tuesday, August 27, 2002, at 10:35 AM, Alexey I. Froloff wrote:

> On Tue, Aug 27, 2002 at 10:03:34AM +0100, Richard Frith-Macdonald wrote:
> > In order to prevent this, I've added use of
> > NSDistributedLock to NSUserDefaults anyway.
> Uh... I don't think that NSDistributedLock is an ultimate
> solution because of timeout

Of course there is no 'ultimate' solution in the sense that any code
can go wrong (your computer could get hit by lightning etc).  What
we aim for is a reasonably reliable solution.
In what way is the timeout a problem?

> (by the way, why 5.0?).

No particular reason ... perhaps a 2 second timeout might be more
reasonable.  It just needs to be somewhere that's long enough so
no normally/correctly operating system should encounter it and not
so long as to hold up a process unduly.

> I have an idea about something like gslockd daemon, that
> handles all interprocess locks. When lock is requested and
> another process (or thread) already have this lock, gslockd
> can check if lock owner still alive and so on...

That's really just what NSDistributedLock is intended for.  It's
designed/implemented the way it is for portability and ease of use.
Use of a special purpose daemon is more complex and gains you little
(you still need timeouts for instance) ... a better chance of
knowing that the process owning the lock is having problems, and
dissociation from the filesystem.  Those advantages might be
important in some applications, but I can't see them providing
any benefit for NSUserDefaults.