On Sat, 2003-01-04 at 06:59, Kaare Rasmussen wrote:
> > Umm. No. User or system level threads, the statement is true. If a
> > thread kills over, the process goes with it. Furthermore, on Win32
>
> Hm. This is a database system. If one of the backend processes dies
> unexpectedly, I'm not sure I would trust the consistency and state of the
> others.
>
> Or maybe I'm just being chicken.
I'd call that being wise. That's the problem with using threads.
Should a thread do something naughty, the state of the entire process is
in question. This is true regardless if it is a user mode, kernel mode,
or hybrid thread implementation. That's the power of using the process
model that is currently in use. Should it do something naughty, we
bitch and complain politely, throw our hands in the air and exit. We no
longer have to worry about the state and validity of that backend. This
creates a huge systemic reliability surplus.
This is also why the concept of a hybrid thread/process implementation
keeps coming to the surface on the list. If you maintain the process
model and only use threads for things that ONLY relate to the single
process (single session/connection), should a thread cause a problem,
you can still throw you hands in the air and exit just as is done now
without causing problems for, or questioning the validity of, other
backends.
The cool thing about such a concept is that it still opens the door for
things like parallel sorts and queries as it relates to a single
backend.
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting