[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 <tacheon@gmx.de> 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
Boris Schaeling <boris <at> highscore.de> writes:
On Thu, 07 Jan 2010 12:22:39 +0100, Tacheon <tacheon <at> gmx.de> 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 <tacheon@gmx.de> wrote:
[...]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 <boris@highscore.de> wrote:
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 <jmalv04 <at> gmail.com> writes:
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