[EMAIL PROTECTED] wrote:
On Feb 13, 2008 1:11 PM, <[EMAIL PROTECTED]> wrote:
It seams to outperform the normal SSH a lot and this speedup looks kinda
impressiv btw.
The speedup looks impressive for 1 connection (because different cores
are computing AES-CTR), but what happens when multiple SCP/SFTP
connections are busy? In this case the normal SSH will run a process
for each connection and the multiple cores are automatically active.
OpenBSD is not good at multithreading so does it make sense to include
this?
Well things need to get improved but that's something where the devs come
into the game and not me. :)
Wasn't there even a discussion about the pro/contra naming such
limitations on undeadly recently?
Sure OpenBSD "may suck" but that doesn't mean the patch isn't usefull some
day. :)
A "none" cipher also should like a bad idea. Just use another file
transfer protocol in that case.
Of course not but it was included into the examples.
Threads are inherently difficult to validate or verify for correctness.
The uncontrolled sharing of memory and other resources between threads
is demonstrably something that is very likely to introduce race
conditions and other subtle bugs.
Historically, threads were a substitute for multiple processes on
systems where process switching was thought to be a performance bottleneck.
A properly engineered solution would use separate processes and a good
interprocess communication system. If shared memory were to be used for
sufficiently demonstrated performance reasons, it would be used with a
good locking system. This could be verified and maintained correctly.
geoff steckel
and maintained.
