[asio] asynchronous reading/writing to the tcp stream
Hello *, I go through the ASIO docs, but somehow do not get if I can implement the following scenario: In one thread I would like to send lot's of commands to the server via a tcp connection. In the other thread I would like to start reading the commands being already handled and returned by the server. The commands are parsed by Spirit.QI. My idea was to use a tcp::iostream asynchronously so that I just pass the begin iterator to the output stream to QI and receive parsed data. If there is no output from the server the iterator should block and wait for it. This is a producer-consumer problem, but I would like to solve it with tcp::iostream and without explicit synchronization on my side. Is it possible? If yes, than how? I understand that I can introduce some storage, read bytes to it and notify my hand-crafter iterator, that there is some data that can be read again, but is there a better approach? Thanks, Ovanes
On Wed, Jul 11, 2012 at 10:44 AM, Ovanes Markarian <om_boost@keywallet.com> wrote:
The commands are parsed by Spirit.QI. My idea was to use a tcp::iostream asynchronously so that I just pass the begin iterator to the output stream to QI and receive parsed data. If there is no output from the server the iterator should block and wait for it.
When you want code that appears to block, but is actually driven by asynchronous I/O, that's a use case for Boost.Coroutine. Interestingly, the new Coroutine is supposed to be reviewed very soon: http://olk.bplaced.net/boost-coroutine.zip I know Oliver will be very glad for your feedback.
On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden <nat@lindenlab.com> wrote:
On Wed, Jul 11, 2012 at 10:44 AM, Ovanes Markarian <om_boost@keywallet.com> wrote:
The commands are parsed by Spirit.QI. My idea was to use a tcp::iostream asynchronously so that I just pass the begin iterator to the output stream to QI and receive parsed data. If there is no output from the server the iterator should block and wait for it.
When you want code that appears to block, but is actually driven by asynchronous I/O, that's a use case for Boost.Coroutine. Interestingly, the new Coroutine is supposed to be reviewed very soon: http://olk.bplaced.net/boost-coroutine.zip
I know Oliver will be very glad for your feedback.
Nat thanks for the quick reply... But what happens with the tcp::iostream if another thread starts to read from it after a connection was open, but no response is there? Would not it block? Is it even safe to write requests to the tcp::iostream from one thread and read it from the other? As I stated before, I would like to solve the issue with ASIO only. I might be able to review coroutine lib, but I don't think this an option for us in this project. Thanks, Ovanes
On Wed, Jul 11, 2012 at 12:05 PM, Ovanes Markarian <om_boost@keywallet.com> wrote:
On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden <nat@lindenlab.com> wrote:
When you want code that appears to block, but is actually driven by asynchronous I/O, that's a use case for Boost.Coroutine. Interestingly, the new Coroutine is supposed to be reviewed very soon: http://olk.bplaced.net/boost-coroutine.zip
Nat thanks for the quick reply... But what happens with the tcp::iostream if another thread starts to read from it after a connection was open, but no response is there? Would not it block? Is it even safe to write requests to the tcp::iostream from one thread and read it from the other? As I stated before, I would like to solve the issue with ASIO only. I might be able to review coroutine lib, but I don't think this an option for us in this project.
coroutine != thread. :-) A coroutine is user-space context switching, and it happens at well-defined times. It's just a way of organizing code that must otherwise be structured to receive intermittent calls -- as with an ASIO completion handler.
On Wed, Jul 11, 2012 at 6:27 PM, Nat Linden <nat@lindenlab.com> wrote:
On Wed, Jul 11, 2012 at 12:05 PM, Ovanes Markarian <om_boost@keywallet.com> wrote:
On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden <nat@lindenlab.com> wrote:
When you want code that appears to block, but is actually driven by asynchronous I/O, that's a use case for Boost.Coroutine. Interestingly, the new Coroutine is supposed to be reviewed very soon: http://olk.bplaced.net/boost-coroutine.zip
Nat thanks for the quick reply... But what happens with the tcp::iostream if another thread starts to read from it after a connection was open, but no response is there? Would not it block? Is it even safe to write requests to the tcp::iostream from one thread and read it from the other? As I stated before, I would like to solve the issue with ASIO only. I might be able to review coroutine lib, but I don't think this an option for us in this project.
coroutine != thread. :-)
A coroutine is user-space context switching, and it happens at well-defined times. It's just a way of organizing code that must otherwise be structured to receive intermittent calls -- as with an ASIO completion handler.
Nat, I know what coroutines, fibers or user space threads are... But using them I still need to do some additional impl, which I don't want. I first want to know if I can read/write to tcp::iostream from two different threads and if yes, than how should I do it best. Thanks, Ovanes
Am 11.07.2012 18:42, schrieb Ovanes Markarian:
I know what coroutines, fibers or user space threads are... But using them I still need to do some additional impl, which I don't want. I first want to know if I can read/write to tcp::iostream from two different threads and if yes, than how should I do it best.
a brief look at basic_socket_iostream I think it is not thread-safe so reading/writing from/to tcp::iostream should force race conditions
On 7/11/2012 12:42 PM, Ovanes Markarian wrote:
On Wed, Jul 11, 2012 at 6:27 PM, Nat Linden <nat@lindenlab.com> wrote:
On Wed, Jul 11, 2012 at 12:05 PM, Ovanes Markarian <om_boost@keywallet.com> wrote:
On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden <nat@lindenlab.com> wrote:
When you want code that appears to block, but is actually driven by asynchronous I/O, that's a use case for Boost.Coroutine. Interestingly, the new Coroutine is supposed to be reviewed very soon: http://olk.bplaced.net/boost-coroutine.zip
Nat thanks for the quick reply... But what happens with the tcp::iostream if another thread starts to read from it after a connection was open, but no response is there? Would not it block? Is it even safe to write requests to the tcp::iostream from one thread and read it from the other? As I stated before, I would like to solve the issue with ASIO only. I might be able to review coroutine lib, but I don't think this an option for us in this project.
coroutine != thread. :-)
A coroutine is user-space context switching, and it happens at well-defined times. It's just a way of organizing code that must otherwise be structured to receive intermittent calls -- as with an ASIO completion handler.
Nat,
I know what coroutines, fibers or user space threads are... But using them I still need to do some additional impl, which I don't want. I first want to know if I can read/write to tcp::iostream from two different threads and if yes, than how should I do it best.
Thanks, Ovanes _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
In my experience, no. tcp::iostream is not thread-safe. What I did was use boost::iostreams to create a separate istream and ostream which wrapped the same raw socket descriptor (since boost::iostreams is not thread-safe either). Andy
participants (4)
-
Michael Chisholm -
Nat Linden -
Oliver Kowalke -
Ovanes Markarian