Re: ideas

Adrian Chadd wrote:

> FreeBSD currently has linuxthreads which will do the same as threads
> do under linux (ie clone() processes with shared data, text and seperate
> stacks) so it could be made to work under FreeBSD.

So someone has breathed life into that project again? Last time I looked
at it the project was idle for more than a year and no longer
maintained, but it was some time ago..

> I would think that systems that support SMP today would support
> smp-aware threading of some sort. Even if its a kludge.

Problem is that is isn't yet true it seems, and still very kludgy making
a hard time to maintain portability.

> I like the idea of automatic crash recovery. Traditionally, I'd look at
> something outside squid (one thing I had in mind was a 'conditional ipfw'
> statement in FreeBSD where the transparent redirection wouldn't happen
> if nothing was bound to the target port). If you have the storage manager
> as a seperate process and it fails, all the existing connections that go
> through the connection manager would fail unless you put in some rather
> interesting logic to try and reconnect the servlets to the clientlets
> (to use my description of the internals) or reschedule new server requests.

Hmm.. a bit of nested logic there.

If a store manager dies, then any cache hits currently being read from
that object directory fails.

If a network I/O manager dies, then any connections currently being
processed by that network I/O manager also dies.

> I'l agree there. THe reason I am going for threads rather than multiprocess
> is simply for SMP. In the non-SMP build you wouldn't have any thread
> primitives. I know various people's opinions for and against using threads.

If designed properly we could still have the possibility to link
everything as one large process, or even use threads if you feel better
about that.

> Ok, Henrik. Lets go for a hybrid for the time being- multiprocess
> as how you've put it above with the clientlet/servlet model I've proposed
> for inside the connection manager. I would like to push for some
> pseudo-code to describe the ideas, rather than lots of English. :-)

Fine.

However the process abstraction level is most appropriate described
using psuedo english rather than psuedo code. Psuedo code works well
when dealing with specific details, while english works well for
describing a design and it's guidelines.

/Henrik
Received on Mon Jun 12 2000 - 18:56:26 MDT