[asio] Modified SSL client to reproduce error
Chris, I took the existing SSL client.cpp code and added a thread to it. I removed the code to prompt the user for a string to send to the server and instead it will randomly pick one of 3 messages to constantly send them. In the 2nd thread, it basically does the same thing, but sends 1 of 3 different messages. Both threads are using the same socket. The first thread is using async IO to read and write the messages. The 2nd thread only sends synchronous messages at random intervals (the first thread picks up the responses from the 2nd thread's asio::write). This program fails rather quickly on Windows XP using MSVS 7.1. First off, did I program this correctly? If so, then I think it can be used to determine some of the SSL issues. :) Thanks, Scott
Hi Scott, Scott <cheesy4poofs@cox.net> wrote:
I took the existing SSL client.cpp code and added a thread to it. I removed the code to prompt the user for a string to send to the server and instead it will randomly pick one of 3 messages to constantly send them.
In the 2nd thread, it basically does the same thing, but sends 1 of 3 different messages. Both threads are using the same socket. The first thread is using async IO to read and write the messages. The 2nd thread only sends synchronous messages at random intervals (the first thread picks up the responses from the 2nd thread's asio::write).
OK, this is almost certainly not going to work :) The thread safety of an ssl::stream is specified such that - distinct ssl::stream objects can be safely used from different threads (although this wasn't the case until 0.3.7) - a single ssl::stream object cannot be used from multiple threads unless protected by some form of synchronisation By synchronisation, I mean something like: - locking a mutex (although this would not be preferred in an asynchronous design) - post()ing a function object into the io_service object associated with the stream, if there is only one thread calling io_service::run(). - post()ing or dispatch()ing a function object into a strand, if you have multiple threads calling io_service::run() Is the change you made to the example representative of how the ssl::stream is used in your application? If so, try adding some form of synchronisation and see what happens. I'd also say that this doesn't sound like the issue that Viktor described, where increasing the size of the buffer made the problem go away. Cheers, Chris
----- Original Message ----- From: "Christopher Kohlhoff" <chris@kohlhoff.com> Newsgroups: gmane.comp.lib.boost.devel Sent: Tuesday, July 18, 2006 4:04 PM Subject: Re: [asio] Modified SSL client to reproduce error
Hi Scott,
Scott <cheesy4poofs@cox.net> wrote:
I took the existing SSL client.cpp code and added a thread to it. I removed the code to prompt the user for a string to send to the server and instead it will randomly pick one of 3 messages to constantly send them.
In the 2nd thread, it basically does the same thing, but sends 1 of 3 different messages. Both threads are using the same socket. The first thread is using async IO to read and write the messages. The 2nd thread only sends synchronous messages at random intervals (the first thread picks up the responses from the 2nd thread's asio::write).
OK, this is almost certainly not going to work :)
The thread safety of an ssl::stream is specified such that
- distinct ssl::stream objects can be safely used from different threads (although this wasn't the case until 0.3.7)
- a single ssl::stream object cannot be used from multiple threads unless protected by some form of synchronisation
By synchronisation, I mean something like:
- locking a mutex (although this would not be preferred in an asynchronous design)
- post()ing a function object into the io_service object associated with the stream, if there is only one thread calling io_service::run().
- post()ing or dispatch()ing a function object into a strand, if you have multiple threads calling io_service::run()
Is the change you made to the example representative of how the ssl::stream is used in your application? If so, try adding some form of synchronisation and see what happens.
I'd also say that this doesn't sound like the issue that Viktor described, where increasing the size of the buffer made the problem go away.
ok I try to reduce code size to some representative example till end of this week cause it seems that my hot fix not solve the problem but only postpone it. sorry for long time but right now I am busy on other project
Cheers, Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Christopher Kohlhoff -
Scott -
viktor kougitko