Boost logo

Boost Users :

Subject: Re: [Boost-users] [asio] multiple simultaneous async_read calls
From: Lee Clagett (forum_at_[hidden])
Date: 2014-08-07 23:11:02


The latest documentation adds this:

This operation is implemented in terms of zero or more calls to the
stream's async_read_some function, and is known as a *composed operation*.
The program must ensure that the stream performs no other read operations
(such as async_read, the stream's async_read_some function, or any other
composed operations that perform reads) until this operation completes.

So a call to async_read cannot be done until the prior one has finished.
This implementation is necessary on some platforms (Linux comes to mind)
because the epoll mechanism merely signals when more data is available for
reading. The async_read function wraps your callback in another callback
that continually polls for data until the requested amount has been read,
then invokes your callback when the read amount has been reached. So
unfortunately, the system call doesn't take the user buffer and notify when
its been filled. That seems ideal, but maybe someone like Nial could
explain the difficulties of such an implementation at the OS level.

Lee

On Thu, Aug 7, 2014 at 10:31 PM, bbxiong <bbxiong.xiao_at_[hidden]> wrote:

> Hello, jason,
> from asio doc:
> async_read will invoke handler one condition is true:
> 1. the supplied buffers are full.
> 2. an error occurred.
>
> so if there is no socket error, async_read will return len1 bytes.
>
>
> My question is, can we make simultaneous async_read calls on one socket,
> will they interfere each other?
>
> Thanks!
>
>
>
> 2014-08-08 10:17 GMT+08:00 Jason Roehm <jasonr_at_[hidden]>:
>
>
>> On 08/07/2014 09:54 PM, bbxiong wrote:
>>
>>> Hello, all,
>>>
>>> If i write some code like this:
>>> boost::asio::async_read(socket_, bosot::asio::buffer(buffer1_.data(),
>>> len1, handler1);
>>> boost::asio::async_read(socket_, boost::asio::buffer(buffer2_.data(),
>>> len2, handler2);
>>>
>>> Will asio guarantee len1 bytes received by the first async_read, then
>>> schedule async_read2?
>>>
>>> or the result is undefined(like several bytes filled into buffer1, then
>>> next several bytes into buffer, then next several bytes into buffer1)?
>>>
>>
>> I don't believe you're guaranteed that you will get `len1` bytes from the
>> first read; it could be shorter. If you want to ensure that you get exactly
>> that size in the first read, you should use the `transfer_exactly`
>> completion condition:
>>
>> http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/
>> reference/transfer_exactly.html
>>
>> Jason
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net