On Mon, Oct 20, 1997 at 05:21:14PM -0500, Manoj Srivastava wrote: > Hi, > >>"Bruce" == Bruce Perens <[EMAIL PROTECTED]> writes: > > Bruce> I think POSIX threads are cool, for _LATER_. Functionality > Bruce> before optimization, please. > > I get paid by people whose exec's made this decision ;-). > > Either we decide to go POSIX threads right now, or we accept > having to rewrite from scratch when(if) we do make it > multi-threaded. Works out cheaper that way. > > I am not yet convinced that we need threads (almost, but the > arguments have not yet reached the critical mass needed). And thread > safe code is not for tha masses (and that fact is paying my mortgage > ;-).
But, we are not the masses... if the programmers we have can handle it, and the code will be well commented, well... why not? > In any case, I don't think we can code without threads now, > and add threads later. This all depends on the degree of threaded-ness. Adding threads later may be fairly easy, if discarding ~10% of current code to do so. The underlying engine in this case would not be much different. But it would be a good idea to make the UI/widget-set side of things thread-safe now, as that would probably need larger changes. But, there are a few issues with using threads:- libc5 doesn't handle threads well. This will limit us to a libc6 implementation only. This probably won't affect us, though. POSIX threads work nicely, _BUT_ they don't handle signals particularly well (LinuxThreads doesn't do POSIX, other implementations do). And, the big question is, what about libslang, libgpm, etc, etc. Are they thread-safe yet? SLang could turn out to be a problem with the signals, because it will need to handle SIGWINCH. If the signals are delivered to one thread only, it will work without necessarily needing to be thread-safe. You just need to put the UI into the "main" threads (i.e. the one that spawns all the others). If you try this under a _TRUE_ POSIX implementation (i.e. signals sent to _ALL_ the threads), there may be large reentrancy problems which occur, and this hurts portability. I would say, if the libraries we are using can handle it, go for using threads, as long as you use them sparingly. Don't optimize the whole thing for speed using threads yet, only for ease of programming. Thanks.
