Re: For the AdaOS folks

["Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca>]

Nick Roberts wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@NoSPAM.cogeco.ca> 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.

There is a little Mach history blurb available at:

  http://hurd.gnufans.org/bin/view/Mach/MachHistory

Presumably if the project started in 1975, the ideas must have been
floating around for a time prior to that.

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

The only suggestion I was making is that if you separate the port from
the thread (the "Mach way" instead of the L4 way where port=thread), then
you don't have the "thread memory overhead" for each "port".  A port
becomes much like a UNIX file descriptor, where a dup(2)-ed file
descriptor just shares an existing file entry (virtually no overhead
- just a pointer and reference count). A port just becomes a nearly
cost-free handle.

As soon as you say every communication end-point implies a thread, then
I as a designer, have to start counting the cost.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg