Torsten Curdt wrote:
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?
Follow the existing example from "Threading Programming Guide", under
the "Using Conditions" section. It's simple and clear. If
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/u
> > What’s the value of SLEEP? -waitUntilDate: can return NO indicating that the
> > timeout elapsed and the lock is not locked; you probably want -wait.
>
> No, I do want the waitUntilDate because I do not solely want to wait
> for the signal.
In that case you probably want to use an NSCondition
Hey Ben
Thanks for quick response.
> What’s the value of SLEEP? -waitUntilDate: can return NO indicating that the
> timeout elapsed and the lock is not locked; you probably want -wait.
No, I do want the waitUntilDate because I do not solely want to wait
for the signal.
So you are saying it shou
Torsten Curdt wrote:
while (!quit) {
[pollingCondition lock];
[pollingCondition waitUntilDate: [NSDate
dateWithTimeIntervalSinceNow:SLEEP]];
[pollingCondition unlock];
...
}
...
}
Is it OK to do it like that? Is there
I have a worker thread that is only slowly polling. I would like to be
able wake him up from a different thread though. A bit like the
select(2) pattern. So what I do is:
...
pollingCondition = [[NSCondition alloc] init];
...
- (void) pollNow
{
[pollingCondition lock];
[
Hey folks,
I have a worker thread that is only slowly polling. I would like to be
able wake him up from a different thread though. A bit like the
select(2) pattern. So what I do is:
...
pollingCondition = [[NSCondition alloc] init];
...
- (void) pollNow
{
[pollingCondition
