Grant Edwards <grant.b.edwa...@gmail.com>: > On 2018-01-20, Marko Rauhamaa <ma...@pacujo.net> wrote: >> 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.
If you mean that user-space software can't create new file descriptor types, you would be painfully correct. The read(2) and write(2) (as well as recv(2) and send(2)) system calls necessarily cross into the kernel-space. User-space file descriptors can be emulated but generally that requires the use of auxiliary processes or threads. If you relax your requirement a bit and let the async framework define its own I/O methods, the magic becomes possible: you can make TLS an asynchronous drop-in replacement for TCP. (I suppose every async framework defines its own I/O methods.) If all you need is a file-descriptor-based notification scheme, Linux can manage that through epollfd, eventfd and timerfd. My async framework does not offer such a notification interface but instead uses callback functions. Marko -- https://mail.python.org/mailman/listinfo/python-list
