Richard Frith-Macdonald schrieb: > > On 9 Feb 2007, at 17:55, Xavier Glattard wrote: > >> >> phew ! >> >> My brain boiled three times (and fried twice) before >> i understand anything... >> And many pieces of code are still quite obscure to me. >> I would not be a very good compiler. >> But i found out what you talk about. >> >> Where you see a performance tweak I see... hum... >> In french i would said 'un sac de noeuds' ;-) >> (bag of knots) > > Well, I'm not sure (would probably need to find the author of that bit > of code and ask them), but I can't see any other reason for bypassing > the run loop like that. I *think* all the calls to the 'calback' method > could probably be commented out. >
As I was the original author of the GNUstep Windows backend code I had a quick look myself. Much has changed here since I last looked at this code, but the callback: method seems to have stayed mostly the same. Which of course is bad, when everything around it has changed. When I originally wrote that code there wasn't much support for Windows message loops in base and not much of it in Cygwin or MinGW. What I implemented at that time as direct polling for messages, the code would ask windows from time to time, if new messages for the application where available. This was a horrible hack, but the best I could do at that time. Later on we added the handling for the Cygwin special file "/dev/windows" and then the code for Windows message handling in base was improved. All of this made the callback: method in back obsolete, but somehow this was missed out by the programmers doing these local changes. It is great that it finally has been noticed by you. This could lead to some simplifications in the code of Win32Server. And while we are at that, why not clean up the code for the different implementations of GSRunLoopCtxt as well? To me it looks like there is quite a lot of duplication going on here, which might be reduced by using subclasses, but then, what do I know about that... Fred _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
