Re: [Boost-users] boost::asio blocking socket read with timeout with multiple threads

Subject: Re: [Boost-users] boost::asio blocking socket read with timeout with multiple threads
From: tom_at_[hidden]
Date: 2018-03-23 11:39:44

> You're right. That poll_read loop consumes the alarm :/
> 
> So then i think the fallback has to be a raw Berkley sockets read against
> the native_handle(), with a signal to cause the EINTR.

Yes, and I've tried basically that method earlier. It works fine, as long as you don't want to use the SSL wrapper, which is what I ultimately want to do. Of course there, you don't have the control to do that. Well, I could write my own socket class variant and wrap that in the SSL wrapper, but that's daft. You can't "test" the socket by using a poll with a timeout, because there may be unprocessed data that the SSL code has read off the socket that it hasn't returned to you yet, so you'd block when actually there was data to return (been there).

There is, as far as I can see, no sensible solution to this. The best I've seen involves mutexes and condition variables, but that's just horrible for what should just consist of passing a timeout value to the poll call. It's just that from the socket class you don't have that control. You DO have that control if you use the basic_socket_streambuf class and wrap the socket in an iostream. That's the odd thing. The functionality IS available in some form, so it's clearly recognised as useful at some level, it's just never been pushed down into the socket itself.