Re: qlimit

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 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?

Now I know why I didn't think of it.  the issue is that display.c is quite a
separate module from console.c.  display.c doesn't know about netfs, and the
virtual consoles, and the nodes.  It is stand-alone.  So far I have managed
to keep it this way.

Of course I could expose netfs_port_bucket, and the netnode structure, and
the vcons_t to display.c and use it this way.  Or I could put the msg
accepted handler in console.c and let it call back into display.c.

But I don't have much against the separate bucket and class for it.  Is
there a good reason not to keep it the way it is, except thread utilization
performance?

BTW, the files are getting longer and longer :)  At some time it might make
sense to split it up into several files, but until it has stabilized, it is
simpler to deal with the way it is.  I also will have to find a place for
the client library and the clients, but this can wait until the code is
there.  Are the makefiles flexible enough to build it all in one directory?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [email protected]
Marcus Brinkmann              GNU    http://www.gnu.org    [email protected]
[email protected]
http://www.marcus-brinkmann.de