Re: qlimit

> 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 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 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.)

> Performance wise, this solution doesn't seem to be better than the earlier
> brute force approach with a send timeout.

I wouldn't expect it to be better than that, it just can be nearly as cheap
and still actually not lose updates (where the client goes idle after a
burst and doesn't see a pending change until the next change after that).

> 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.  But still, only
100 of those switches are explicit (maybe call it 200 with all the
msg-accepted notification futzing) and then there's just time-sharing if
the client were ever nonidle (but I wouldn't think it ever would be when
not driven by a change notice message).