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

[Charles Davis]

Sorry I waited so long to get back to you.

On 3/10/11 3:27 PM, Ken Thomases wrote:
> On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote:
> 
>> I doubt Alexandre would accept reworking wineserver around CFRunLoop,
I know. Then again, I've often wondered if doing this might be
beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5.
>> but I can think of several alternatives:
Unfortunately, each of them has a disadvantage. Quite frankly, I'm not
liking our options at this point.
>>
>> 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.
Yeah. That makes me think AJ might not accept this, either. Then again,
it's not like this thread will actually be servicing requests from Wine
processes. Personally, I like it the best (or rather, hate it the least)
of all the options you mentioned.
>>
>> 2) Do this in Wine's userland, like in a service.
But then we'd suffer the overhead of (even more) IPC. It's bad enough
that we have to talk to the server, but this way the app has to talk to
wineserver to talk to a service, and the service has to talk to
wineserver so it can talk back to the app. That's a lot of IPC, and
that's something I'd rather avoid if possible. Plus, it seems to me that
the inotify/dnotify support would have to be reworked in terms of this;
otherwise, we'd have to have ugly #ifdef blocks in ntdll's change
functions (in addition to the ones already in the server).

Alternatively, we could just have the change functions run the run loop
themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to
waiting for directory changes. I'm not sure how you or AJ feel about
that, though. We'd still have to have #ifdef blocks in ntdll, though, if
we do it this way.
>>
>> 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.
If we do it this way, we may as well just spin off a new thread
(suggestion 1). It's cheaper to spawn threads rather than processes.
There's an argument to be made for saving Unix handles in the server,
but I don't think saving one handle (the write end of a pipe) just for
this is worth it. There's also the whole "wineserver should be
single-threaded" argument, but I already wrote about that under 1).
> 
> 4) Use kqueue directly, with its vnode filter.  It would entail opening every directory in a hierarchy, which might be deemed prohibitive.
We could run out of Unix handles pretty quickly if we do it that way. As
I recall, the limit on the number of open FDs a process can have is
pretty low by default (only 2560 on my system). Of course, the user
could raise this limit (the hard limit is unlimited), but still I don't
feel comfortable painstakingly opening tens, hundreds, possibly even
thousands of file descriptors at once just to watch for changes to them.

Chip