Re: [boost] async_read SEGFAULT

Subject: Re: [boost] async_read SEGFAULT
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2019-01-08 02:15:26

On Tue, 8 Jan 2019 at 03:22, hh h via Boost <boost_at_[hidden]> wrote:

> Thanks Richard, I was wandering the strand real role, thanks for the
> explanation.
>
> As you pointed out the two life time static buffers one for read one
> for write should be the same as the life time of the socket attached
> to each session. In a server, there could be more than thousand
> session connections, in terms of resource management, would you think
> it is good or bad idea if to use a global buffer pool management class
> so the global buffers can be shared by all sessions?
>

When writing software for high concurrent use, you have to assume that at
some point, every client will read and write at the same time.
Whether you use some centralised buffer resource or not, your total maximum
working set size will be the same in either case.
In this case you're better off allocating the maximum memory a session will
need and having it owned by the session because if you run out of resources
due to too many sessions, its better that it happens before the session is
connected than half way through the user's operations.

Therefore, if your server is able to handle (say) 5000 clients at the same
time, you may as well allocate the memory for 5000 connections at program
start (or even statically). If you don't have enough memory, better to know
early!

>
> One thing is clear, that a fixed size array like boost::array<char,
> MAX_SIZE> readBuffer for each session async_read should not be used
> (which I am currently using), allocate and reserve more than thousands
> MAX_SIZE buffer in memory is not going to work.

It depends how big your MAX_SIZE is. If it's (say) 100k (a huge buffer for
most use cases) then 1,000 concurrent connections requires 1000*2*100k =
200Mb. 200 megabytes is not a lot of memory in a modern server.

> I'll have to see if it
> can be replaced by other boost simple smart buffer like
> boost::asio::buffer which can be converted to a raw pointer char* for
> feeding msgpack unpack input. (Vinnie did mention to use beast, might be
> another option, I have to see how complicated that will be)
>

asio::buffer creates a "buffer definition object" i.e. an object that
describes the address and size of the actual buffer memory. Be careful
about this. The asio ConstBufferSequence concept does not model actual
memory, it models the idea of a sequence of "memory references". This is a
slightly unclear (in my view) part of the documentation. It's worth looking
at the example code, building it and single-stepping though it.

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>