gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSound Reimplementation


From: Wolfgang Lux
Subject: Re: NSSound Reimplementation
Date: Tue, 30 Jun 2009 08:36:41 +0200

Richard Frith-Macdonald wrote:

On 28 Jun 2009, at 21:46, Wolfgang Lux wrote:

Stefan Bidigaray wrote:

I tried setting waitUntilDone to YES, still no luck! The - _finished method still doesn't get called when calling - performSelectorOnMainThread:..., for now I've just made that a - performSelector:withObject:, which works, but is not what I want done. I guess my next question here is: is - performSelectorOnMainThread:withObject:waitUntilDone: working? Maybe I built -base incorrectly?

I don't think so. The problem with - performSelectorOnMainThread:withObject:waitUntilDone: is that the call is only scheduled to be executed by the run loop of the main thread. Thus, the call will not be executed before the next event is received or the next timer expires on the main thread.

Not exactly ... calling - performSelectorOnMainThread:withObject:waitUntilDone: also triggers an event in the run loop of the main thread (by writing to a pipe that the thread is listening to), so as the pipe will wake up a sleeping thread, the call should be executed pretty much immediately (though after any other work already in progress, or waiting to execute) as long as the loop is running.

Ah well, I did overlook this when skimming over NSThread.m. So now I understand the point of threadInfo->inputFd in GSRunLookCtxt :-)

This is indeed different from Mac OS X, where the scheduled call seems to be executed immediately if the run loop is idle.

OSX is supposed to behave the same way as GNUstep... it should handle the perform on the next run loop iteration, so if the loop is not being run the perform should be held up until it is.

Maybe the runloop is not running, or maybe it's running, but not in the mode that was specified for the method to be performed in?

There is a subtle difference between OS X and GNUstep: As far as I understand the code, threadInfo->inputFd is not even checked if the run loop has no event sources and no timer and it is just added implicitly to the event sources in -pollUntil:within: in GSRunLoopCtxt. On OS X, on the other hand, (the equivalent of) threadInfo->inputFd automatically becomes an input source once the thread starts a new thread. So, if you call NSRunLoop's - runMode:beforeDate: in GNUstep after starting a new thread without adding a timer or an input source, it returns immediately with NO and it does not perform an invocation scheduled by the secondary thread, whereas on OS X -runMode:beforeDate: performs the scheduled invocation and then returns YES. If I find time, I'll try to make up a test case.

Wolfgang





reply via email to

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