[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:48:36 +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 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

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?


`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]