The objective is to create sslhandshake like application to allow us to measure performance of SSL_poll().

Looks like we agree the SSL_poll() design comes with O(n) for every iteration of event loop which drives I/O non-blocking application. We know it's mostlikely bad, but we don't know how much bad it might be.

What I'd like to do is to create application which will utilise two threads:

• server thread which uses SSL_poll() to manage non-blocking I/O
• client thread which uses SSL_poll() to manage non-blocking I/O

The client thread should try to open C connections. each connection will establish S streams to read/write data from server. The read/write operation will be using memory buffers only (no disk I/O). Each stream should carry fixed amount of data (10kB for example). We can measure how much time it takes to get this done.

This should be good enough to detect performance regression in QUIC/Poll API. This approach won't give us performance data to compare with competitors.