Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I think what we need is:
>
> - on the client side, a wake_server_and_sleep() call that combines the
> write()+read() on the socket in a single syscall.
>
> - on the server side, a wake_client_and_wait_for_next_one() that wakes
> the client whose request was last processed, and waits until some
> other client sends a request.
This is fairly pointless... the Linux system call overhead isn't all that
major - issuing separate send & receive calls loses you very little. Beyond
the fact that the server may be busy doing something else, the real killer is
the pair of context switches and the fact that there is no guarantee that the
server will immediately be scheduled after the client, and the client again
after the server.
Indeed, it may be necessary to swap the server back in, depending on system
load.
> This should enable doing a complete server round-trip with only two
> syscalls (one in the client one in the server), and avoid any
> unnecessary context switch.
Like the two switches to get to the server and back again?
> If we combine this with an efficient way to read/write the client
> memory space from the server, I think we should be able to achieve
> good performance while still reusing nearly all the existing code.
True, some sort of ptrace-type access mechanism may help speed things up
without tying up ptrace.
> And if the mechanism is small enough and generic enough, we can even
> hope to have it included in the standard kernel, which I doubt would
> ever be possible with the complete server kernel module.
As Patrik implied... Unlikely (though he said it more eloquently).
David Howells
