[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qlimit

From: Marcus Brinkmann
Subject: Re: qlimit
Date: Mon, 24 Jun 2002 13:01:44 +0200
User-agent: Mutt/1.4i

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.


`Rhubarb is no Egyptian god.' Debian address@hidden
Marcus Brinkmann              GNU    address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]