From: Jim I. <ji...@ap...> - 2005-05-02 16:50:29
|
Daniel, On Apr 30, 2005, at 7:04 AM, Daniel A. Steffen wrote: > Jim, > > On 29/04/2005, at 15:01, Jim Ingham wrote: > >> The design goal here was to keep the Mac OS X Tcl a pure Unix Tcl. >> > > I definitely agree with this in general, we should certainly not > make any changes which e.g. would prevent us building on pure Darwin. > However, given that we already have CoreFoundation dependencies > with the CFBundle code, I don't think the CFRunLoop additions would > be a further departure from that goal. In any case it will be easy > to switch back to the unix notifier by just changing the makefile, > or we could even make the choice of notifier a configure option. Yes. We need to do this anyway, because CF is not available to 64 bit apps, and some people might be interested in a 64 bit Tcl... > > >> It's fine to change the Mac OS X Tcl over to use CF specific >> code, but it does add to the support cost. >> > > I don't really think this is true if you consider that the current > differences between tkMacOSXNotify.c and tclUnixNotfy.c as just > about as big as the ones between the new tclMacOXNotify.c and > tclUnixNotfy.c. > Actually, I suspect the fact that the macosx notifier will be in > the tcl sourcetree will make it more likely that somebody making > changes to tclUnixNotfy.c will also update tclMacOXNotify.c (all > the tclUnixNotfy changes since 2004-06-22 had not made it into > tkMacOSXNotify...) > tkMacOSXNotify.c won't go away altogether, though this is quibbling at this point. I am actually fine with your changing this. One important thing to remember is that however you do it, you have to arrange that all the calls you make into Carbon run on the Carbon main thread of the application - where Carbon main thread is defined to be the thread which first loaded the HIToolbox framework. That was one of the things I liked about using the threaded Tcl, it got all the Tcl wait stuff off of the main thread, and made it very easy to grab the main thread for Carbon. If you don't do this you will get all sorts of odd behavior. The Carbon guys are still explicit about this - in particular they don't support anything that calls a callback into your code running on anything but the Carbon main thread. This came up most recently in a discussion of multi-threading support for QuickTime 7, but they've said it many times in the past. The first couple of versions of the Mac OS X notifier that I experimented with didn't do this - running the Carbon wait on a worker thread, and they would almost work, but then we would get these mysterious deadlocks down in Carbon. In fact, I managed to get it all the way working on DP4, but then it broke in 10.0 and I never could figure out how to make it work there (though I spent some time peering through the CF & Carbon sources). So for the sake of all our sanity, I think this needs to be a hard requirement of whatever design we end up with. It also isn't worth trying to play games to get the Carbon main thread to be anything but the application main thread. The Java guys tried to work this out for a couple of years (before they switched to Cocoa) and it caused them no end of trouble. > >> I don't find this area of the code particularly fun to work on, >> so I didn't want to make work for myself in this area. If you & >> Daniel are interested in maintaining this code, however, that's >> great... Go for it... >> > > I'm certainly happy to maintain this, FWIW it shouldn't be very > different to maintaining current tkMacOSXNotify.c... Cool. Jim > > Cheers, > > Daniel > > -- > ** Daniel A. Steffen ** "And now for something completely > ** Dept. of Mathematics ** different" Monty Python > ** Macquarie University ** <mailto:st...@ma...> > ** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/> > > |