Re: [boost] [asio] SSL operation sporadically returns "Access is denied"

From: Scott (cheesy4poofs_at_[hidden])
Date: 2006-09-29 12:17:29

Hi Chris,

> I was about to write to say that I ran your previous test
> program for about half an hour without any problems.

Wow.  That doesn't make sense.  It fails for me in 5 seconds or less.  I'm
running on a 2 CPU system, so that may make a difference.

> Rather than using a mutex, a better approach would be to use an
> asio::strand object. You can use a strand to wrap your handlers
> and they won't be executed concurrently (see the last timer
> tutorial for an example). A mutex will *not* give the correct
> behaviour in the case of "composed" operations like
> boost::asio::async_write. (Note: i'm assuming you're using the
> latest code in CVS here.)

I grabbed the code in boost CVS about 2 weeks ago.  Should I get latest
again?
 
> However, I am not confident that the current SSL wrapper
> implementation is thread safe even if you use a strand. It may
> simply be safer at this time to stick to using an individual SSL
> object from a single thread. In practice that means only calling
> io_service::run() from a single thread.

For the client, that's probably acceptable.  But for the server we really
need multiple threads.  Is it okay for each thread to create it's own
io_service to solve this problem?

> What exactly is it that you want to do with the second thread?
> There may be another way of structuring it to give the same
> effect while keeping all access to the ssl/socket object from
> the one thread.

Well, the current client design works like this.  The client is an MFC UI
application.  We spawn a background thread inside io_service::run() to
handle incoming asynchronous communications.  The server can send responses
to the client at any time.  In other words, the client might send a request
to the server to monitor the CPU utilitization on the server.  In that case,
the server will send a CPU packet roughly every second with the current CPU
value.  The io_service thread would receive the packet, push the response
into a callback queue and notify the MFC UI thread via a windows message
that it has a waiting server response.

In addition, the UI thread may, in response to some user action, make other
synchronous requests for the user (on the same socket, which apparently is a
bad idea?).  Those synchronous requests are dispatched to the server.  The
reply is handled in the same manner (callback via windows message).

So, if I understand correctly, the UI should *not* be using the socket class
because we spawn a background thread to receive data on that socket?

Thanks,
Scott