First -- it needs to use timeIntervalSince1970 to be using the same reference date required for pthread_cond_timedwait
Second -- lockWhenCondition needs to loop because pthread_cond_timedwait can return prior to delay expiring (but with the wrong condition).
Third -- Internally the lock was incorrectly being unlocked on a delayed acquire (and YES return). And was incorrectly being unlocked a second time when the timeout expired.
Also, fixed a problem with tryLockWhenCondition:
By calling lockWhenCondition: it would incorrectly report a deadlock (rather than just return no) when we already have the lock.
All these changes are in line with expected and documented behavior for NSLock.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29472 72102866-910b-0410-8b05-ffd578937521
I think that's all of the classes that use GSIMaps for their implementation now fully supporting fast enumeration. If there are any that I've missed, then just copy the methods from GSSet to implement them. You just need to set the mutations pointer to something sensible (i.e. something that will change if the collection mutates) and then call the new GSIMapCountByEnumeratingWithStateObjectsCount() function.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29181 72102866-910b-0410-8b05-ffd578937521
As with GSArray, GSSet uses its isa pointer for detecting mutations. This may change as a result of adding KVO notifications, so it might not be the best solution, but I can't currently think of a way we could catch isa changing to [GSMutableSet class] and not changing to a hidden class...
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29179 72102866-910b-0410-8b05-ffd578937521
Some of these implementations are not as efficient as they could be (especially the ones that take an NSIndexSet as the first argument). They also don't yet support concurrent enumeration. Apple implements these using Grand Central. We could possibly have a background thread that we send these things to (or use GCD if libdispatch is available). It's not worth spawning a new thread for them, except in exceptional circumstances (and, unfortunately, we can't easily tell how expensive a single iteration of a block is. Possibly we could time one block invocation, and if it's longer than some threshold make it concurrent, but it's probably not worth the effort).
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29176 72102866-910b-0410-8b05-ffd578937521
NSArray *a= [NSArray arrayWithObjects: @"a", @"b", @"c", nil];
FOR_IN(NSString*, o, a)
NSLog(@"%@", o);
END_FOR_IN(a)
This is equivalent to:
for (NSString *o in a)
{
NSLog(@"%@", o);
}
On clang, it will be expanded to exactly that. With GCC, it will be expanded to something equivalent to the code that Clang (or Apple GCC) would expand this to.
This is a private GNUstep header and is not intended for general use. Outside of GNUstep, please use fast enumeration directly.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29170 72102866-910b-0410-8b05-ffd578937521
Any blocks will have their isa pointer set to the two classes statically allocated in libobjc, but these classes can't be used for message lookup (or introspection) until after the call. This means that you can't send messages to blocks until after NSObject's +load method has been called. This shouldn't be a problem in most code, but if you use __attribute__((constructor)) instead of a +load method then be careful about sending messages to blocks (you can still call them as normal).
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29144 72102866-910b-0410-8b05-ffd578937521
and correct some formatting.
* Source/synchronization.m: Fix @synchronize support on
Windows. The __weak__ attribute doesn't work on Windows.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@29140 72102866-910b-0410-8b05-ffd578937521
