Re: MT string, to do next

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Thu, Mar 16, 2000 at 10:31:27PM -0800, Benjamin Kosnik wrote:
> No. The config script looks for:
>       i486 | i586 | i686 | i786)
> 	cpu_include_dir="config/cpu/i386"
>         ;;
> Note that i386, the thing that you (Nathan) are so concerned with, uses:
>       *)
> 	cpu_include_dir="config/cpu/generic"
>         ;;
> Thus, no traps. Since Uli has made this a non-issue anyway, it's not 
> really important. I just thought I'd clarify...

In that case, the config script shouldn't do anything different for i386 
than for the other x86es.  Anyway, there is no cpu/generic/atomicity.h.  
So I would suggest

-       i486 | i586 | i686 | i786)
+       i386 | i486 | i586 | i686 | i786)
 
> Ulrich is right, we can't cripple the c++ library for ancient hardware. 

Please.  Nobody argued for crippling the library for ancient hardware.
 
> The question I have is if this same approach for primitives can be used 
> for IO-locking, or if a pthreads approach is required. ...
> Obviously, including pthread.h is a no-no, when we have the config work 
> done to select between thread types (ie, use c++threads.h and typedef 
> pthread_mutext to mutext_type or something.) That is, if a thread library 
> is the way to go here...

To support locking, we need locking primitives. In particular, we need 
some way to wait until some other thread releases the lock.  That implies
a task queue, and context switch, and thus a thread library.

Nathan Myers
ncm@nospam.cantrip.org