Re: [boost] [beast] write_some EWOULDBLOCK/EAGAIN error recovery non-blocking operations

Subject: Re: [boost] [beast] write_some EWOULDBLOCK/EAGAIN error recovery non-blocking operations
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2017-07-04 13:54:09

בתאריך 4 ביולי 2017 3:23 ×œ×¤× ×”×´×¦,‏ "Gavin Lambert via Boost" <
boost_at_[hidden]> כתב:

On 4/07/2017 08:21, Vinnie Falco wrote:

> On Mon, Jul 3, 2017 at 1:18 PM, Artyom Beilis
>
>> I strongly recommend doing full testing of everything in non-blocking
>>
>> mode because
>> (a) It is VERY common to mix them so you MUST work correctly
>> regardless the socket configuration.
>> (b) It provides a huge performance advantage especially for small
>> blocks over multiple connections since it reduces need for callback
>>
>
> Oh trust me, I know. A carefully written non-blocking mode server can
> handle thousands of connections and in the fast-path requires
> resources proportional to N = the number of threads rather than the
> number of connections. So I will be doing what I can to make this work
> and make it part of the public interface.
>

It's unfortunate that (as I understand it) async I/O on Linux isn't
implemented very well.  Async I/O on Windows is significantly superior to
non-blocking I/O, and if it were the same on Linux then you would just
never use non-blocking I/O at all (since after all it's mostly a hack
anyway).

Actually on the contrary. On most Unix like platforms  you can do both
reactor and proactor style of operations efficiently. epoll, /dev/poll and
kqueue based operations can be simply transformed into proactor operations
while competition port is limited to proactor operations only.

The major difference is when you can complete the operation immediately you
don't want to pay the price for callback as callback has a significant
price.

that's why non blocking operations are so useful

Artyom