Issue #90 was closed with "blocking (synchronous) API is not a goal for fastwebsockets" — curious about the reasoning behind this.
Is the core frame parser fundamentally tied to AsyncRead + AsyncWrite, or is it more of a scoping/maintenance decision?
Asking because we run latency-sensitive WebSocket consumers on CPU-pinned threads with non-blocking TcpStream + epoll busy-polling (no async runtime). The frame parsing performance of fastwebsockets is very appealing, but wrapping it in a single-threaded tokio runtime adds indirection we'd prefer to avoid.
If the frame codec were generic over Read + Write (with the async variant as a thin wrapper), it would open up fastwebsockets to a wider set of use cases without changing the async API. Happy to contribute if this is something you'd consider.
Issue #90 was closed with "blocking (synchronous) API is not a goal for fastwebsockets" — curious about the reasoning behind this.
Is the core frame parser fundamentally tied to
AsyncRead + AsyncWrite, or is it more of a scoping/maintenance decision?Asking because we run latency-sensitive WebSocket consumers on CPU-pinned threads with non-blocking
TcpStream+ epoll busy-polling (no async runtime). The frame parsing performance of fastwebsockets is very appealing, but wrapping it in a single-threaded tokio runtime adds indirection we'd prefer to avoid.If the frame codec were generic over
Read + Write(with the async variant as a thin wrapper), it would open up fastwebsockets to a wider set of use cases without changing the async API. Happy to contribute if this is something you'd consider.