discuss-gnustep
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]