[asio] Why are the strands in the "HTTP Server 3" example necessary?
In the HTTP Server 3 (http://tinyurl.com/yh95d2b) example of the asio documentation strands are used to synchronize the invocation of completion handlers? But why are they necessary here? As far as I get it, the handlers are invoked in strict sequential order for each distinct connection (http://tinyurl.com/ybohynd). Each connection has its own set of resources so synchronization shouldn't be necessary, should it? Thanks in advance, Boris
On Thu, 07 Jan 2010 12:22:39 +0100, Tacheon
In the HTTP Server 3 (http://tinyurl.com/yh95d2b) example of the asio documentation strands are used to synchronize the invocation of completion handlers? But why are they necessary here? As far as I get it, the handlers are invoked in strict sequential order for each distinct connection (http://tinyurl.com/ybohynd). Each connection has its own set of resources so synchronization shouldn't be necessary, should it?
I quickly checked the connection class and couldn't find a reason either why strand is used here. The comment in connection.hpp (///Strand to ensure the connection's handlers are not called concurrently) doesn't make any sense as a new asynchronous operation is only started when another ends. Maybe the strand is left over from an earlier version of the HTTP server? Boris
Boris Schaeling
On Thu, 07 Jan 2010 12:22:39 +0100, Tacheon
wrote: In the HTTP Server 3 (http://tinyurl.com/yh95d2b) example of the asio documentation strands are used to synchronize the invocation of completion handlers? But why are they necessary here? As far as I get it, the handlers are invoked in strict sequential order for each distinct connection (http://tinyurl.com/ybohynd). Each connection has its own set of resources so synchronization shouldn't be necessary, should it?
I quickly checked the connection class and couldn't find a reason either why strand is used here. The comment in connection.hpp (///Strand to ensure the connection's handlers are not called concurrently) doesn't make any sense as a new asynchronous operation is only started when another ends. Maybe the strand is left over from an earlier version of the HTTP server?
Boris
I were just wondering because the example is mentioned in the strand-section of the overview. So this might just be a bad example? I am still not sure about this. In the strand-overview (http://tinyurl.com/ya7g5g3) there is also a passage about composed operations and intermediate handlers which I don't understand. It might be that this is true for the HTTP 3 example.
On Fri, 08 Jan 2010 09:22:06 +0100, Boris Haeberlein
[...]I were just wondering because the example is mentioned in the strand-section of the overview. So this might just be a bad example?
I just checked the other strand example at http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/tutorial/tuttimer5..... This makes sense to me but not the HTTP server 3.
I am still not sure about this. In the strand-overview (http://tinyurl.com/ya7g5g3) there is also a passage about composed operations and intermediate handlers which I don't understand. It might be that this is true for the HTTP 3 example.
A composed operation is eg. async_read() which "is implemented in terms of zero or more calls to the stream's async_read_some function" (see http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/reference/async_rea...). But the HTTP server 3 calls async_read_some() through a strand (which is not a composed operation). The HTTP server 3 also calls async_write() which is a composed operation. However I can't see any intermediate handlers (there is no other asynchronous operation started after async_write() is called; thus there is no handler which could be called between handlers invoked by async_write_some() - the asynchronous operation async_write() is composed of). Boris
On Thu, Jan 7, 2010 at 10:11 PM, Boris Schaeling
I quickly checked the connection class and couldn't find a reason either why strand is used here. The comment in connection.hpp (///Strand to ensure the connection's handlers are not called concurrently) doesn't make any sense as a new asynchronous operation is only started when another ends. Maybe the strand is left over from an earlier version of the HTTP server?
I am using an all but identical implementation without the strands for quite some time now without any problems. They appear entirely superficial as far as I can see. Cheers, Stephan
I am using an all but identical implementation without the strands for quite some time now without any problems. They appear entirely superficial as far as I can see.
Hi, The strands are not required in the example but would be if the example was improved to include timeouts (which I recall Chris was planning to) regards
Jose
Hi,
The strands are not required in the example but would be if the example was improved to include timeouts (which I recall Chris was planning to)
regards
That seems to be convenient. When there is more then one handler is active at a given time, the strand makes sense to me. So may be the example should be revamped eventually. Or it shouldn't be declared as a strand example, at least.
participants (5)
-
Boris Haeberlein -
Boris Schaeling -
Jose -
Stephan Menzel -
Tacheon