Failing kernel32:change and ntdll:change tests on Mac OS

[Ken Thomases]

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