On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden wrote:

On Wed, Jul 11, 2012 at 10:44 AM, Ovanes Markarian 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 6:27 PM, Nat Linden wrote:

On Wed, Jul 11, 2012 at 12:05 PM, Ovanes Markarian wrote:

...

On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden 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

On 7/11/2012 12:42 PM, Ovanes Markarian wrote:

On Wed, Jul 11, 2012 at 6:27 PM, Nat Linden wrote:

...

On Wed, Jul 11, 2012 at 12:05 PM, Ovanes Markarian wrote:

...

On Wed, Jul 11, 2012 at 5:10 PM, Nat Linden 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