On Mar 10, 2011, at 2:47 PM, Charles Davis wrote: > The Change Notification tests all fail miserably on my machine (a 2009 > Mac Pro with Mac OS X 10.6), because that feature hasn't been > implemented on Mac yet. > > I could implement it for 10.5 up, but the problem is that the "public" > API for Change Notifications on Mac (the "FSEvents" API, in > CoreServices.framework) expects clients to either use a CFRunLoop or (on > 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ.
> I guess the real question is, which way should we do this? If we do it > the first way (using the public and documented but kqueue-unfriendly > Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer > concerned about Leopard, a GCD dispatch queue) in its main loop, and if > we do it the second way (using the undocumented and unstable but > kqueue-friendly Unix API), wineserver needs to run as root, and may need > to cope with API changes. Based on what I've heard, I'm leaning toward > the second way, but I want your guys' input before I go ahead. The second way strikes me as truly hideous. I doubt Alexandre would accept reworking wineserver around CFRunLoop, but I can think of several alternatives: 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. 2) Do this in Wine's userland, like in a service. 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. Regards, Ken