Patrik Stridvall <[EMAIL PROTECTED]> writes:
> Everything that is speed critical should be in kernel,
> things that are not should not. Trying to do it
> some other way is doomed to failure I think.
That's *exactly* what I'm proposing: the speed critical part (the
request mechanism, since it is used for all server calls) in the
kernel, all the rest in user space.
> > - 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.
>
> Urk... Good luck getting that into the kernel.
> I think hell will freeze over before that happends.
>
> One thing that Linus Torvalds absolutely hate is a random collection of
> API:s. He wants them to have some sort of concept behind them.
Obviously I'm not suggesting that we add these two functions as system
calls; this is only the conceptual interface. The actual
implementation should probably be based on file descriptors; basically
it is a kind of pipe with slightly different semantics (you could even
achieve most of that with normal pipes, but you'd need to always
transfer 4096 bytes to keep the buffer full which would be a bit
slow).
> Also note that they also have the potential to be misused in a DOS
> (Denial of Service) attack unless carefully implemented and not
> unlikely with a large performance cost.
I must have missed something here. Could you explain where you see a
problem, and what performance cost it would cause?
> > 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.
>
> True, however the abillity to selectively choose a specific process
> to yield to doesn't fit very well with the CONCEPT of a time sharing
> system.
You don't have to do that; all you need is to ensure that client and
server are not runnable at the same time to avoid unnecessary context
switches.
--
Alexandre Julliard
[EMAIL PROTECTED]
