[adrian@creative.net.au: Re: ideas]

Trigger-friendly fingers .. oops.

----- Forwarded message from Adrian Chadd <adrian@creative.net.au> -----

Date: Mon, 12 Jun 2000 23:34:30 +0800
From: Adrian Chadd <adrian@creative.net.au>
To: Henrik Nordstrom <hno@hem.passagen.se>
Subject: Re: ideas
User-Agent: Mutt/1.2i

On Mon, Jun 12, 2000, Henrik Nordstrom wrote:
> Adrian Chadd wrote:
>
> > Ok. Your definition of a 'connection manager' is a combination of my
> > 'clients/servlets'.
>
> Yep. Network I/O manager is probably a more appropriate name for that
> component.
>
> My discussion centers around finding the borders which could be broken
> into separate execution units, where a execution unit is a thread or
> process. The initial sketch is for processes to also allow the design to
> be resistant against stupid faults in one execution unit.
>
> Your 'let' discussion centers around the actual request forwarding, and
> have different metrics in the design.
>
> One does not exclude the other. It is simply different startingpoints
> aming at somewhat different goals. Most likely both ideas can be
> implemented without any major conflict between the two.

Yup. I was just trying to understand exactly what we are both getting at.
I'll move to your discussion since it dictates the request forwarding
protocol somewhat.

My plan was to have one thread for IO/callback like now, and then one thread
(at least) per FS. This is pretty much the squid design. Thinking
more about SMP, I was looking at one thread for IO/callback per CPU.
With my let system, it shouldn't be too hard to make it work with
SMP if you assume a couple of limitiations - specifically that 'lets'
won't cross thread boundaries. They can miagrate between threads but
not cross threads. This doesn't make sense at low load, but I'm
thinking that at higher loads it will be better than trying to handle
inter-thread communication.

The storage manager poses an interesting problem in SMP. Do you try to
make it totally SMP happy or do you do much like the above - all
clientlets talking to servlets/storage manager'lets' will be in one
thread, eliminating the need for a lot of inter-thread communication?
How will that perform at low and high loads?

I'm not an SMP/threads person so the only way for me to get my head
around the issues is just to code it up and play.

Now, how much further do we want to break it down? Breaking out
(say) the DNS code into a thread might make sense, but do you
think it will be worth it?

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.
----- End forwarded message -----
-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.