> On 12 Jul 2016, at 10:43, Fred Kiefer <fredkie...@gmx.de> 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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev