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