[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NSRunLoop different behaviour to Cocoa?
From: |
Stephen Brandon |
Subject: |
NSRunLoop different behaviour to Cocoa? |
Date: |
Wed, 16 Jan 2002 10:10:11 +0000 |
Hi,
According to the MacOSX Cocoa docs, NSRunLoop:-currentMode is supposed to
return nil if the runloop is not currently running. I'm pretty sure that this
is the only way to tell if there is no currently running runloop.
>From the Cocoa docs: "currentMode returns the current input mode ONLY while
the receiver is running. Otherwise, currentMode returns nil."
In the SndKit I use a delegate messaging system for the start/end of playing
sounds which communicates from the background playing thread to the
foreground thread using DO. For this to work there needs to be a NSRunLoop
running in the main thread. For "Tool" projects this is often not the case,
and I need to be able to ascertain the presence of a runloop before
attempting to set up the DO, else the DO hangs and fouls things up (same on
MacOSX and GNUstep).
ANYWAY, the GNUstep implementation of NSRunLoop:-currentMode ALWAYS returns a
valid mode, whether or not the runloop is running. (NSRunLoop.m:796 the mode
is set in -init).
I *think* this should be considered a bug (though I have not compared to the
official OpenStep spec).
I've had a very quick look at the GNUstep NSRunLoop source, and I can't see a
trivial way to determine whether or not the NSRunLoop is running, sufficient
to gate the return value from -currentMode to nil.
Can anyone fix/advise/tell me of a better way of determining the presence of
a valid runloop?
Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk
- NSRunLoop different behaviour to Cocoa?,
Stephen Brandon <=