On 2018-01-20, Marko Rauhamaa <ma...@pacujo.net> wrote: > Grant Edwards <grant.b.edwa...@gmail.com>: [...] >> I won't argue with that. I think that non-blocking ssl-wrapped >> sockets _should_ have the same select/poll/send/recv API/semantics >> that normal sockets do. I thought about writing my own >> wrapped-ssl-socket class that does that, but using stunnel was just so >> much easier. If you _did_ want to wrap sockets like that, I think >> you'd need to actually run a thread to deal with the SSL socket and >> provide a "proxy" socket or pipe for use with select/poll. >> >> Basically you'd be doing what stunnel does only doing it in-process. > > Stunnel is fine for many applications but not for our needs. Also, a > subsidiary thread is not necessary. Everything can be done within an > async framework (in C anyway).
Of course it can. But (ISTM) either the async framework has to be SSL-aware, or the sockets have to be wrapped and "proxied" using another socket or pipe -- I don't see how else you can provide something that has the same select/poll and send/recv semantacs that an unwrapped, non-blocking socket provides. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
