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-22 09:56:01

> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152.aspx

Yes, sorry. Yes, you can create pipes in Windows, but asio doesn't support Windows anonymous pipes or concole handles, as they don't support completion ports. But yes, you can create a named port with a unique name (which is what CreatePipe does).

>   You're in a shared memory space, and ASIO is itself a queued-task 
> management system, and you can store arbitrary state for each task 
> (including completely unique structures for each task, if you really 
> want).  Just store the data you want to process directly in the object 
> that you're posting to the other io_service, then store the result in 
> the object that you post back for completion.

Whilst this is true, what it doesn't give you is any flow control. So consider implementing something like an HTTP upload. Front end loop will go as fast as it can reading off the input socket, each time into a new buffer. For each read it then posts some kind of job to the io_service, wrapped in a strand to ensure sequential operation. If the backend doesn't keep up, you end up with an enormous backlog within the io_service, and enormous memory usage. What you really want is an async write to a pipe to a backend. That way, when the pipe is full, the write doesn't complete. Since it doesn't complete, no new data will be read from the socket, so the TCP buffers backup, client write them blocks. Perfect.

Anyway, I'm going off by pattern anyway. I don't see it offers any advantage over just a synchronous thread per connection design.

Using async initially, then sync to read the "message" works well, it's a nice design, if only I could put a timeout on the synchronous reads.