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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev