Kalle Olavi Niemitalo wrote:
>
> Neal H Walfield <[EMAIL PROTECTED]> writes:
>
> > An application sends a message to a server; jump into kernel. Mr. Kernel
> > says, is this ok to do? Hmm, I need to check with Mr. Auth server, in user
> > land.
>
> Each client has a send right to a port; the server has receive
> rights for all those ports. When a client sends a request, the
> server sees which port it came through and then checks the
> privileges associated with that port to see whether the request
> should be fulfilled.
In any case, the complaint remains: It is slow.
I will benefit from being an 'outsider', before I start to get
influenced by the 'obviously necessary' design contraints, to throuw out
a few ideas:
In both cases, the interaction appears 'synchronized (pardon me for
using this word, I don't know another one) of the type:
loop
get next request
if validate request
then
get data
honor request
send data
endif
endloop
Why not this:
loop
while validated request is waiting
remove request from queue
honor request
send data
endwhile
get next request
queue request up for validation
get data // Just in case validation OK, (major case ?)
endloop
That would permit 'asynchronous' reception and honoring of requests, not
waiting for validation, but going on immediately to the next request.
This depends on how validation is done, fo course, if several
validations can not be done in parallel, then nothing is gained.
I know this adds a complexity level to the processing, but I would
defend a solution like that (if it works) by saying that it is easy to
follow because of the obvious need to 'continue right away'. As long as
the average time to validate a request < the time to get it, get data
and honor it, it should be OK ...
Any comments?
Atle
