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