Hey Greg
> You're not following the pattern laid out in the Overview setion of the
> NSCondition class reference. In particular, you don't have a boolean
> predicate, and you're not doing the task's work between the bounds of lock
> and unlock.
Hm ... but if I surround my task's work with lock/unlock wouldn't this
block the calling thread until the worker thread has done it's work?
- (void) pollNow
{
[pollingCondition lock];
[pollingCondition signal];
[pollingCondition unlock];
}
...which is absolutely not what I want.
Essentially I want something along the lines of this pseudo code:
function workNow() {
signal = YES
}
function worker() {
while(1) {
wait for 1000ms or signal == YES
signal == NO
do some work
}
}
> "A boolean predicate is an important part of the semantics of using
> conditions because of the way signaling works. Signaling a condition does
> not guarantee that the condition itself is true. There are timing issues
> involved in signaling that may cause false signals to appear.
Right. I read that. But for me false signals are not a problem. I
don't really need that guarantee. My only concern is to not have the
thread waiting without going through the loop from time to time.
cheers
--
Torsten
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
