Boost :: Beast Non Blocking是否可以读取Websocket？

Question

We have an app that is entirely synchronous, and will always be because it is basically a command line interpreter to send low level commands to our hardware, and you cant have two commands going to the hardware at the same time. I will only ever have 1 client socket for this configuration operating in a synchronous manner, one command to the server, it talks to hardware, and sends value back to client, but as far as i see it currently async_read is the only way to do non blocking reads.

What is the best way to get a non blocking read/write via Beast? For example in TCP and Serial in Windows you have ways to peek into the buffer to see if data is ready to be accessed, and if there is you can issue your read command knowing it wont block because data is there. Not sure if I am just missing this functionality in Beast, although i will say having such functionality if possible would be nice.

Anyways so based on this i have a question

First, can I take the Coroutine example and instead of using yield, to create and pass it a read_handler function?

I've taken the coroutine example, and built the functions into my class, and used the exact same read_handler from this thread answer. How to pass read handler to async_read for Beast websocket?

It compiles as he says, but setting a break point never triggers when data is received.

I dont really need the full async functionality like the async example, pushing it into different threads, in fact that makes my life more difficult because the rest of the app is not async. And because we allow input from various sources(keyboard/TCP/Serial/File), we cant block waiting for data.

Answer 1

What is the best way to get a non blocking read/write via Beast?

Because of the way the websocket stream is implemented, it is not possible to support non-blocking socket modes.

can I take the Coroutine example and instead of using yield, to create and pass it a read_handler function?

If you want to use completion handlers, I would suggest that instead of starting with the coroutine example you start with one of the asynchronous examples, since these are already written to use completion handlers.

Answer 2

Coroutines have blocking semantics, while completion handlers do not. If you try to use the coroutine example and replace the yield expression with a completion handler, the call to the initiating function will not block the way it does when using coroutines. And you should not use spawn. You said that the coroutine example is much easier, probably this is because it resembles synchronous code. If you want that ease of writing and understanding, then you have to use coroutines. Code using completion handlers will exhibit the "inversion of control" typically associated with callbacks. This is inherent to how they work and not something you can change by just starting with code that uses coroutines and changing the completion token.