On 2016-02-28 10:36:25 +0100 Richard Frith-Macdonald
<richard.frith-macdon...@brainstorm.co.uk> wrote:
On 28 Feb 2016, at 09:20, Riccardo Mottola
<riccardo.mott...@libero.it>
wrote:
Hi,
I experience lately problems with "someone broke our lock" issues
and other
Lock related exceptions.
I have experienced this on NetBSD, OpenBSD and Linux, clang or gcc,
it is
not OS nor compiler dependant. It happens on plain uniprocessor
computers.
I know that Gregory had some issues too. Greg, maybe you can add
information?
Usually the nuiseance happens when launching a GS application when
one is
already running (e.g. one runs Terminal or GWorkspace and launches
application X).
I think that latley it is happening really a lot.
The most common thing is that you canot start an application and get
a
popup. Retrying a couple of time helps.
Sometimes, like what happened just to me, you leave things running
and get
back to the computer and found one app died leaving that in the
console.
Maybe writing defaults is related, but it could be something related.
It surely makes using more apps and thus having a Desktop quite have
a bad
thing now. I think we need to dig it out before release. The issue
is... I
have no way to reliably reproduce that
It sounds like you are probably talking about filesystem locks
(inter-process) rather than processor (inter-thread) locks.
NSUserDefaults uses NSDistributedLock to ensure that only one process
updates
the persistent defaults at a time, so you could try looking there.
If I'm to look into it under debug, I really do need at least a way
to
reproduce the problem though.
I started GWorkspace and saw this:
/System/Tools/fswatcher: Uncaught exception NSGenericException,
reason: Unable to get attributes of lock file we made
Then I started GNUMail (to report hits error) and saw this:
Warning ... someone broke our lock
(/home/multix/GNUstep/Defaults/.lck/.GNUstepDefaults.lck) ... and may
have interfered with updating defaults data in file.201
Does this give you any ideas? This is on NetBSD/x86/clang it happens
often, but not always...
Riccardo
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
