Gavriel State <[EMAIL PROTECTED]> writes:
> Another thing that this reminds me of is the discussion over the
> wineserver - for winelib apps that don't expect to be doing lots
> of communication across several processes, wouldn't it be nice to
> not have a seperate executable and process for the wineserver?
> For single threaded apps this might allow us to see similar
> performance gains as with the proposed kernel-module wineserver....
If the app is single-threaded and doesn't use communication across
processes, then it will basically not call the server at all, so you
won't see any performance difference... (OK, there is the exception of
file I/O, which is far from optimal at the moment; I hope we can find
a better mechanism for that).
The kernel module approach is interesting, but I'm afraid it's not
really practical to reimplement the complete server in the kernel,
unless we can somehow build both the kernel module and the user-mode
server from the same sources. An intermediate approach that may be
worth investigating is to keep the server in user-space but implement
a faster request mechanism with a small kernel module; Unix sockets
are not very well suited to the request/reply model that we need, and
I think it should be possible to make the communication much faster
with a specialized kernel call.
--
Alexandre Julliard
[EMAIL PROTECTED]
