Comments on Replacing C

[Hal Murray]

How well do the languages/systems you are considering support threading?

I think we should be careful not to over-focus on translating the current 
single-threaded code.


What should our code look like in the long term?  Will crypto chew up a lot 
of cycles?  Could a busy server support more clients by running several 
threads in parallel on multiple CPUs?

Is there any reason not to use multiple threads?

Would we actually gain anything from multiple threads?  Would they all merge 
back together queuing up for the crypto hardware?  I've seen good comments 
about the performance of Intel's crypto accelerators but don't remember the 
context.  Is the extra hardware one per chip, or one per CPU?

Maybe we should write some test code.

--------

Eric has occasionally said non-good things about threads.  The context was 
mostly the DNS stuff from the current code which is admittedly ugly.  (Maybe 
we should add fixing that to the list.)

I've always considered threads to be no-big-deal.  Maybe that's because I 
learned about them when I worked with people who got the architecture right 
and the language supported it.  Mesa/Cedar from Xerox/Parc back in the 
70s/80s had locking supported by the language.  You could say "ENTRY 
PROCEDURE" and it would lock the module lock when entering that procedure.  
"INTERNAL PROCEDURE" meant that it could only be called if you already had 
the lock.  There was another form for locking a record (aka struct).


-- 
These are my opinions.  I hate spam.