Re: Threads

[Tom Lees <tom@lpsg.demon.co.uk>]

On Mon, Oct 20, 1997 at 05:21:14PM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Bruce" == Bruce Perens <bruce@pixar.com> 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.