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 <[EMAIL PROTECTED]> Copeland Computer Consulting ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
