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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
