From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Thu, 6 Jan 2005 00:57:39 +0000 Message-ID: References: <1PTAd.1218$0y4.421@read1.cgocable.net> Content-Type: text/plain; charset=us-ascii X-Trace: individual.net aIKw8reAHaRSoeVznwZCgQqLCzAtM6UpdcOIAcM0NhCwuoDPA= X-Orig-Path: not-for-mail User-Agent: Gemini/1.45d (Qt/3.3.2) (Windows-XP) Xref: g2news1.google.com comp.lang.ada:7507 Date: 2005-01-06T00:57:39+00:00 List-Id: "Warren W. Gay VE3WWG" wrote: > Mach's roots go back to 1975, which is quite some time ago ;-) Blimey, I didn't know that. I started designing the microkernel that has become Bachar in the mid 1980s. Certainly I had never heard of Mach at that time. > However, the "name service" for example, will often have many clients > (only one receive port for the name service, but at least one send-right > for every client "task" on the system). This is one example where the > numbers of send-rights can be large. My current plan is that every process (except one, the Top Process) will have recourse to a 'parent' (actually an 'inner parent') process, from which, among other things, it can request a resolution of a named environment variable. Normally, name servers would be obtained, queried, and then discarded, to resolve each step of a path (starting at an environment variable). However, this means that every process will have to be issued with at least one service key -- the one to call its parent -- for the lifetime of the process. Avarus is the process that will have the most direct (inner) child processes, typically in the ball park of 50 to 100 per workstation, so that's 100 service keys for a start. All of those service keys /could/ be serviced by just one thread (and one IPC service). However, it might be better to have each serviced by its own separate thread (operating at an appropriate priority). So, that might require 100 threads within Avarus just for that purpose alone; there would surely be many more threads for other purposes. Looking at my Windows XP Task Manager just now, I see 47 processes and 446 threads. Interesting. I'm not sure if it's a problem. Currently, I anticipate capacity for 500 processes and 1500 threads (per workstation), and for 1000 IPC services and 3000 service keys. Each (normal) thread will eat up about 300 bytes of RAM (for the TSS and ring 0, 1, and 2 stacks). The RAM used up for an IPC service or service key is negligible. How would Mach do it better? -- Nick Roberts