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@mansionfamily.plus.com>
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