Re: "concurrency" branch updated

[Ken Raeburn]

>>> What do we have in TLS that we don't have in any network connection?
>> 
>> Encryption, optional compression, possibly key renegotiation, possible 
>> receipt of incomplete messages that can’t yet be decrypted and thus can’t 
>> give us any new data bytes.
> 
> Doesn't all that become insignificant compared to network latencies?

Not if I’m requesting a large amount of data from the server at once, or 
pipelining requests, or talking to multiple servers at once; I could have a 
steady stream of encrypted data coming in, and the latency from making a 
particular request to getting the corresponding response may not be important.

Whether the bandwidth available is enough that decrypting plus parsing 
(assuming we’re encrypting some network protocol and not an opaque file 
transfer) plus updating data structures plus UI updates plus the occasional GC 
is more than one thread can keep up with, that’s the question….  With 
additional C-level threads for managing TLS connections, we can at least take 
the decryption part out of that list and run it concurrently, without needing 
full Lisp-level thread support.

Ken