Re: [boost] [asio] Pass some parameter to io_service::run

Subject: Re: [boost] [asio] Pass some parameter to io_service::run
From: Dmytro Ovdiienko (dmitriy.ovdienko_at_[hidden])
Date: 2010-01-10 12:46:07

Hello James,

Thanks for your responce.

The large object is message_parser. It is 'large' because it encapsulates
'parsing rules' and 'message protocol'. Also it is stateful. So, on your
question it is 'temporary application state'.

On ownership. Right now message_parser is owned by worker_thread. The
incoming message processing sequence is following:

1. Reactor calls ::select function on udp::sockets
2. ::select notifies about incoming data
3. Reactor enqueues socket to the queue
4. worker_thread dequeues socket from the queue
5. worker_thread calls ::recv on dequeued socket
6. ::recv stores incoming data to the buffer
7. worker_thread passes buffer to the message_parser::parse
8. message_parser returns incoming_message
9. worker_thread processes incoming_message

So the light-version of the structure is:

Application := udp::socket*, worker_thread*, Reactor
worker_thread := incoming_buffer, message_parser

If number of sockets = 60 and worker_count = 4, I have only 4
incoming_buffers and 4 message_parsers.

With Boost Asio I will have 60 incomming buffers. Though it is not a
problem. Buffer size is 64k. The problem is message_parser. It uses ~5MB
...maybe more.

I expect to have structure something like:

Application := udp_socket*, worker_thread*, Reactor
worker_thread := message_parser
udp_socket := udp::socket, incoming_buffer

But I don't know how to pass message_parser to the socket's completion
handler.

2010/1/10 James Mansion <james_at_[hidden]>

> Dmytro Ovdiienko wrote:
>
>> I need to pass reference to this object to the socket::async_receive
>> complete routine to complete message processing. This object allocates a
>> lot
>> of memory and I cannot create it for every socket. It is possible to
>> create but there is no sense.
>>  In this case I should create LargeObject for every socket because I don't
>> know what thread of the pool will process incoming message. And I cannot
>> pass the same largeObject to two or more recv operations.
>>
>> Looks like I should use null_buffers. What is overhead of this way? Should
>> I
>> go to the kernel twise (1st - socket::async_recv, 2nd - socket::recv)?
>>
>>
>
> I'm confused by the first two statements.
>
> Is the large object 'large' because it is the receive buffer, or does it
> contain temporary application
> state?
>
> I guess the question is whether the object is owned by:
> - the IO operation while it is in progress
> - the socket
> - the completion handler thread while it handles the completion
>
> If it contains the buffer and you don't want to pre-allocate lots of them
> (ie when you start the IO)
> then the null buffer optimisation may help, but I'm surprised you would
> need to have enough UDP
> end points that this is an issue - surely one uses UDP to enable
> multiplexing lots of client systems
> to each endpoint? You probably don't need bufers larger than a jumbo fram
> anyway do you?
>
> James
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>