I should have suggested lock instead of tryLockUntil: [NSDate
distantFuture]. (I don't really use NSLock, since my threads are generally
lower-level stuff than Cocoa.) There's nothing that won't work the way I
suggested, but the tryLockUntil is just unnecessary. Sorry for putting a bit
of cruft in
Hi
I wrote a little app to do deep folder watching on Windows servers
from a Mac and am getting crashes when directories are added or
removed from the watch directory. The directory scanning takes place
in a thread and I tried to isolate the array from outside changes by
locking it, but
Found a partial solution but it's ugly. If I copy the array before
enumerating it, no more crashes, but I'd prefer to not add that
overhead...
On Dec 22, 2008, at 9:24 AM, Ken Tozier wrote:
Hi
I wrote a little app to do deep folder watching on Windows servers
from a Mac and am getting
The lock (the same one) has to be used by all the methods to coordinate
access. Taking a lock in updateDirectoriesInThread doesn't magically make
addDirectory and removeDirectory wait for the lock.
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
Unless that busy flag is only used for UI display or debugging info, lose
it. The lock is the way to coordinate access, you can't do that by checking
a flag.
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
If you can target Leopard and above, @synchronized is probably a
better route to go though as scott said, the object to be synchronized
around would need to be checked by all methods using it (in your case
this would be the instance of the NSLock).
-rob.
On Dec 22, 2008, at 10:12 AM,
How would one share a lock? Should I make it a property of the class?
And then what? According to the NSLock documentation, multiple calls
to tryLock are a no no, so how does one determine the current state of
a lock? I didn't see any methods like isLocked
On Dec 22, 2008, at 10:12 AM,
On Mon, Dec 22, 2008 at 10:22 AM, Ken Tozier kentoz...@comcast.net wrote:
How would one share a lock? Should I make it a property of the class? And
then what? According to the NSLock documentation, multiple calls to tryLock
are a no no, so how does one determine the current state of a lock? I
On Dec 22, 2008, at 10:30 AM, Kyle Sluder wrote:
Nowhere does the documentation say this. You can't call -[NSLock
lock] multiple times, because you'll block on a lock you already have
(that's why we have recursive locks). Otherwise -[NSLock tryLock]
would be quite useless, wouldn't it?
On Mon, Dec 22, 2008 at 10:42 AM, Ken Tozier kentoz...@comcast.net wrote:
You should not use this class to implement a recursive lock. Calling the
lock method twice on the same thread will lock up your thread permanently.
Use the NSRecursiveLock class to implement recursive locks instead.
It
Given that, could you give a really simple example of how to
coordinate access between the three methods?
First, your lock is an instance variable of the class, so in init you alloc
init it, and in dealloc you release it...
- (void) methodA
{
[myLock tryLockBeforeDate: [NSDate
On Dec 22, 2008, at 9:42 AM, Ken Tozier wrote:
Problem is, I'm a thread noob so have no idea which type of lock is
right for my situation. As to @synchronized, Robert Marini seemed to
suggest that that was a Leopard-pnly solution. This app has to work
on Tiger as well.
As a self
On Mon, Dec 22, 2008 at 10:22 AM, Ken Tozier kentoz...@comcast.net wrote:
How would one share a lock? Should I make it a property of the class? And
then what? According to the NSLock documentation, multiple calls to tryLock
are a no no, so how does one determine the current state of a lock? I
13 matches
Mail list logo
