Am 12.07.2016 um 13:47 schrieb Richard Frith-Macdonald <[email protected]>:
> >> On 12 Jul 2016, at 10:43, Fred Kiefer <[email protected]> wrote: >> >> I made some progress here although I am still not satisfied with the >> result. It turns out that >> >> [[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantPast]]; >> >> is a NOP with current GNUstep base. It may have been different some time >> ago, but now when the limit is in the past this method returns immediately. >> Richard could you please confirm that this is the intended behaviour? >> >> If we replace that line with >> >> [[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode >> beforeDate:[NSDate distantPast]]; >> >> we get the expected behaviour. You could use this code for now to get >> your application working correctly under GNUstep. But on MacOSX none of >> this hacks should be needed. Riccardo, could you please try to run FTP >> with that runloop line removed on a Mac and report back whether the >> progress bar gets filled smoothly? >> >> To me this looks like we are having an issue with background threads >> that run their own runloop. As this is an area where I am not very >> familiar it would be great if Richard could take over. > > It would help to have more regression tests ... we have a lot of code written > to match the documented behavior, and where that can be interpreted in > different ways we get differences between OSX behavior and GNUstep. > I added a few testcases for this and tried it out under OSX, and it seems > -runUntilDate: should cause timers to fire even when called with > nil/distantPast. I'v modified svn trunk to do that. > It also seems that -acceptInputInMode:beforreDate: should fire timers > (whether there is input available or not) ... but fixing that would be a > bigger change. Thank you Richard, with that change the old code works again as expected. Fred _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
