Re: qlimit

[Marcus Brinkmann]

On Mon, Jun 24, 2002 at 01:11:54AM -0400, Roland McGrath wrote:
> > The handling of the notification ports is a bit annoying.  I had to
> > create a class and bucket and donate a service thread to retrieve the
> > kernels responses.
> 
> Why not just put the notification ports in the normal bucket and let the
> existing manage_multithread handle them?

I guess that would work, I just need to change the demuxer.  I think I
didn't think of it.
 
> I don't think there would be any harm in just using the protid port as the
> notify port.  The user could forge a mag-accepted notification, but that
> will just cause you to attempt another send and have it fail with
> MACH_SEND_NOTIFY_IN_PROGRESS.  Am I missing something?

I don't think it is harmful for the server if a user does that.  I am not
sure if it is 100% safe for the client in not losing any updates, but that's
not a problem for the server.

> > I am not sure what the destination port is here, if it is the client port
> > we try to send to, we have a problem.  Because a send-once notification
> > doesn't let us know which clients port died, so we can not find the correct
> > filemod_req structure belonging to this request.  
> 
> But we can use it as an alert to scan for dead names.  And there are very
> few to scan, only the ones in msg-accepted wait.  (Ports that are still on
> the active list we will notice next time there is a change and we get
> MACH_SEND_INVALID_DEST on the send attempt.)

Yes, I thought of that.  I have to put that in.

> > Without clients, the server needs 30s to process the find command, with
> > one client it needs 50s, with two clients it needs 53s.  I don't know why
> > it needs 20s more with one client attached.
> 
> That could be a little suspect, but OTOH the difference is removing a whole
> other task and all the context switches to and from it.

D'oh you are right.  Sometimes I need a can opener for my eyes to see such
things :)  I was not measuring the server time at all, but the real time of the
find task, which of course is affected by that.  That's good.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de