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

[Ken Thomases]

On Mar 21, 2011, at 8:52 AM, Charles Davis wrote:

> 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.

I have a vague recollection of that, too, but we seem to have worked around it.  kqueue is working well enough.  The problem with CFRunLoop is that it's implemented really stupidly for sources which are not Mach ports, file descriptors in particular, at least on older versions of Mac OS X.


>>> 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.

Is the overhead material, though?  I don't know that file change notification is such a high-frequency API that the calls back and forth will be a significant portion of total program time.  After all, it's all ultimately gated by disk I/O.

> 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.

I have to confess I haven't read the current inotify/dnotify-based implementation.


>>> 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).

The point of using a separate process is that it minimizes the exposure of wineserver to bugs, either in our new code or in the Mac frameworks.  Currently, for example, the wineserver is only linked against libgcc and libSystem.  That's another desirable quality, like its single-threaded nature.

> It's cheaper to spawn threads rather than processes.

We're talking about one process, right?


>> 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.

Hence, "deemed prohibitive". ;)

Regards,
Ken