gmane.comp.lib.boost.asio.user

Re: Socket MT safety

Gruenke, Matt — 2012-05-23T18:33:47

Yes, I think you can safely use a mutex to protect access to the socket.

 

Another option would be to break your handlers into multiple pieces,
dispatching to the strand just for the part that accesses the socket.
Use of multi-stage handlers is also more in keeping with Asio idioms and
might scale better, in some cases.

 

 

Matt

 

 

From: Nikki Chumakov
Sent: Wednesday, May 23, 2012 13:32
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Subject: [asio-users] Socket MT safety

 

From: Igor R <boost.lists< at >gm...> - 2012-05-23 17:10

That was kind of misunderstanding. As far as I remember, I meant that
the OP could call async_read when async_write is in progress, and vice
versa, without waiting for completion of the former (eg., as opposed
to calling async_read twice). Not that it can be done from different
threads.

 

OK, I see.

 

So, may I just protect all calls to the socket methods with mutex,
without using strands to serialize the calls of completition handlers? I
really want my

Re: Socket MT safety

Marat Abrarov — 2012-05-23T18:32:43

It is safe to use mutex with Asio composed operations (http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/asynchronous_operations.html) if you implement custom (locking) asio_handler_invoke (http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/asio_handler_invoke.html). See https://github.com/boostcon/2011_presentations/raw/master/mon/thinking_asynchronously.pdf (template <class Handler>
struct mutex_wrapper) for details.

Regards, 
Marat Abrarov.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://

Re: Socket MT safety

Igor R — 2012-05-23T18:08:12


To my understanding, it's not safe, because you should (but can't)
also protect all the subsequent calls to async_read_some() made by a
composite operation.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Re: Socket MT safety

Gruenke, Matt — 2012-05-23T17:56:49

No, not if you only have <= 1 operation in flight at a time.
Synchronous and unidirectional protocols should generally fall into this
category.


Matt


-----Original Message-----
From: Marsh Ray 
Sent: Wednesday, May 23, 2012 13:42
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Cc: Gruenke, Matt
Subject: Re: [asio-users] Socket MT safety


OK, so what about the multithread case?

Does that effectively always need a strand around a socket?

- Marsh

On 05/23/2012 11:30 AM, Gruenke, Matt wrote:


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxl

Re: Socket MT safety

Marsh Ray — 2012-05-23T17:42:04

OK, so what about the multithread case?

Does that effectively always need a strand around a socket?

- Marsh

On 05/23/2012 11:30 AM, Gruenke, Matt wrote:


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Socket MT safety

Nikki Chumakov — 2012-05-23T17:32:09

From: Igor R <boost.lists< at >gm...> - 2012-05-23 17:10

That was kind of misunderstanding. As far as I remember, I meant that


OK, I see.

So, may I just protect all calls to the socket methods with mutex, without
using strands to serialize the calls of completition handlers? I really
want my read and write handlers to work concurrently in different threads.

There is a statement in asio manual which make me unsure:


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/asio-users
___________________

Re: Socket MT safety

Igor R — 2012-05-23T17:09:42


That was kind of misunderstanding. As far as I remember, I meant that
the OP could call async_read when async_write is in progress, and vice
versa, without waiting for completion of the former (eg., as opposed
to calling async_read twice). Not that it can be done from different
threads.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Re: Socket MT safety

Gruenke, Matt — 2012-05-23T16:48:41

Use io_service::strand::dispatch().  Unless the strand is currently in
use, it will execute immediately.

 

http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_se
rvice__strand/dispatch.html

 

 

Matt

 

 

From: Nikki Chumakov
Sent: Wednesday, May 23, 2012 12:36
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Subject: Re: [asio-users] Socket MT safety

 


From: Gruenke, Matt <mgruenke< at >Ty...> - 2012-05-23 15:45


That means that it's safe to concurrently use different sockets, but not
to concurrently access the same socket from different threads.  Even if
you find that it works, be advised that future changes might break any
code relying on it.
You can fix this by posting all handlers to a strand for that socket.

 

The design and nature of my application prevents from using strands over
handlers. There is full duplex consumer/producer data flow, and
read/write handlers works almost independently from each other. The only
synchronization point I need between handlers

Re: Socket MT safety

Nikki Chumakov — 2012-05-23T16:35:59

From: Gruenke, Matt <mgruenke< at >Ty...> - 2012-05-23 15:45


The design and nature of my application prevents from using strands over
handlers. There is full duplex consumer/producer data flow, and read/write
handlers works almost independently from each other. The only
synchronization point I need between handlers is for handling read/write
timeouts and to close socket gracefully in such cases.

I believe if I wrap the handlers with strands it impact the latency.

I saw the clauses that some socket async methods can be used concurrently.

E.g. http://lists.boost.org/boost-users/2011/01/65911.php

*From:* Igor R (*boost.lists_at_[hidden]*)



That why I want to know it for sure.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats.

Re: Socket MT safety

Yuri Timenkov — 2012-05-23T16:35:10

At least there can be race in which error will you get: invalid descriptor
or socket closed. All IO operations call is_open (IIRC) but close() closes
socket and resets descriptor back to invalid.

Otherwise all low level operations should be synchronized by OS:
technically it's the same as calling send() and/or recv() from different
threads or even processes (on Unix).

More severe races could be when additional processing takes place, e.g.
when using SSL.

On Wed, May 23, 2012 at 5:51 PM, Nikki Chumakov <nikkikom-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
asio-users

Re: Socket MT safety

Gruenke, Matt — 2012-05-23T16:30:47

No strand should be needed if you have only one thread calling
io_service::run().


Matt


-----Original Message-----
From: Marsh Ray
Sent: Wednesday, May 23, 2012 11:53
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Cc: Gruenke, Matt
Subject: Re: [asio-users] Socket MT safety

On 05/23/2012 10:45 AM, Gruenke, Matt wrote:

ISTR someone reporting that on at least one OS (MS Windows I think) they
found the socket close notification could get dispatched concurrently
with another handler for that same socket. Assuming that handlers access
their socket, this would seem to imply that for correctness every socket
effectively MUST be handled in some strand.

Or am I misremembering or missing something?

- Marsh

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobil

Re: Socket MT safety

Marsh Ray — 2012-05-23T15:52:44

ISTR someone reporting that on at least one OS (MS Windows I think) they 
found the socket close notification could get dispatched concurrently 
with another handler for that same socket. Assuming that handlers access 
their socket, this would seem to imply that for correctness every socket 
effectively MUST be handled in some strand.

Or am I misremembering or missing something?

- Marsh

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/asio-users
____________________________________________

Re: Socket MT safety

Gruenke, Matt — 2012-05-23T15:45:08

Here's what the docs say:


    THREAD SAFETY

    Distinct objects: Safe.

    Shared objects: Unsafe.


Source:
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/basic
_socket.html


That means that it's safe to concurrently use different sockets, but not
to concurrently access the same socket from different threads.  Even if
you find that it works, be advised that future changes might break any
code relying on it.

You can fix this by posting all handlers to a strand for that socket.


Matt


-----Original Message-----
From: Nikki Chumakov
Sent: Wednesday, May 23, 2012 09:52
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Subject: [asio-users] Socket MT safety

Hi,

Would like to ask just for clarification.

Assuming my code (including competition handlers) is MT-safe

- can I call basic_socket's async_read and async_write methods from two
different threads for the same socket instance without synchronization?

- can I call "async_read" (or "async_write") and "cancel" met

Socket MT safety

Nikki Chumakov — 2012-05-23T13:51:57

Hi,

Would like to ask just for clarification.

Assuming my code (including competition handlers) is MT-safe

- can I call basic_socket's async_read and async_write methods from
two different threads for the same socket instance without
synchronization?

- can I call "async_read" (or "async_write") and "cancel" methods from
different threads?

- can I call "async_read" (or "async_write") and "close" methods from
different threads?

- can I call "close" and "cancel" methods from different threads?

Regards,
Nikki

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxl

Re: Boost/Asio "short read" error

vf — 2012-05-22T08:25:32

Actually, it is not something to worry about.

Normally this error code is returned when the SSL client does not close its
connection properly, i.e. without calling SSL_shutdown() (terminated from the
task manager, for example).

The connection is closed by the client one way or another, the server can do
nothing but ignore it.

You can check this error code as follows:
if (error.category() == boost::asio::error::get_ssl_category() && 
error.value() != ERR_PACK(ERR_LIB_SSL, 0, SSL_R_SHORT_READ)) // boost returns
"short_read" wehen the peer calls SSL_shutdown()
{
   // the client went down abruptly
}


Better still, search the boost asio source code for "short_read" (without
quotes). The comments are rather explanatory.
 


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, m

Re: Boost/Asio "short read" error

Marcin Głogowski — 2012-05-22T07:43:31

Hello,
Thank you for the hint!
I didn't suspect the SSL.
Please write me - which version of SSL is stable without the bug?
Best regards and thank you for help
Marcin


Dom Maklerski Banku Ochrony Środowiska Spółka Akcyjna
ul. Marszałkowska 78/80 / 00-517 Warszawa

wpisana w Rejestrze Przedsiębiorców prowadzonym przez
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego
pod numerem: KRS 0000048901 / NIP 526-10-26-828

Kapitał zakładowy w wysokości 21.551.200zł wpłacony w całości.

P - Nie drukuj tej wiadomości, jeśli to nie jest konieczne.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________

Re: reusing SSL sessions in ASIO sockets

vf — 2012-05-22T05:59:50

Some time has passed since your posting....
However, the links you included in your test program indicate one must shutdown
the original SSL channel (control channel in this case) by calling
SSL_shutdown() before re-using the session with the new SSL connection (e.g
'Resuming an SSL Connection' section in
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html).

'Sharing' the session between two live SSL connections might work (by accident)
as long as there are no 'simultaneous' transmissions on those connections.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+

Re: Boost/Asio "short read" error

vf — 2012-05-22T01:21:22

Are you using SSL? It sounds like an SSL error.





------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Re: thread::interrupt and asio::ios_service::run

Gruenke, Matt — 2012-05-21T15:27:57

The concern I have with thread::interrupt() is the potential for it to introduce race conditions.  There are simplistic cases, such as where you’re just using it on a single thread that only communicates with the cancelling thread, in which I agree that it’s not hard to use safely.

 

When discussing io_service::run(), it might help to think of it as a giant dispatch loop, as opposed to the sense in which the current cancellation points are like leaf nodes in the call graph.  As I see it, making io_service::run() into a cancellation point is not a well-bounded problem.

 

 

Matt

 

 

From: Yuri Timenkov
Sent: Monday, May 21, 2012 04:30
To: asio-users< at >lists.sourceforge.net
Subject: Re: [asio-users] thread::interrupt and asio::ios_service::run

 

Hi Matt,

interrupt() doesn't lead to any resource leaks or missed cleanup. If you look closer into documentation you'll see that interrupt() throws a boost::thread_interrupted exception from well-defined cancellation points which is

Re: thread::interrupt and asio::ios_service::run

Yuri Timenkov — 2012-05-21T08:30:15

Hi Matt,

interrupt() doesn't lead to any resource leaks or missed cleanup. If you
look closer into documentation you'll see that interrupt() throws a
boost::thread_interrupted exception from well-defined cancellation points
which is caught in boost::thread's thread-main function. As with any other
exception stack will be unwound automatically and thread gracefully
finished.

If you write your program in exception-safe manner nothing leaks.

The problems may arise if you're unaware of these cancellation points.
Imagine you call join() from object destructor while one itself might be
executing in boost:thread. If someone interrupts this thread, you'll get
exception thrown from destructor which results in undefined behavior.

In other regards I'd like to see io_service::run as a cancellation point.

Best wishes,
Yuri

On Sat, May 19, 2012 at 9:04 AM, Gruenke, Matt <mgruenke-1xCVI8+nB4ZBDgjK7y7TUQ< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
Live Secur

Re: thread::interrupt and asio::ios_service::run

Gruenke, Matt — 2012-05-20T05:56:25

I'm not aware of a naive way to cleanly shutdown an arbitrarily-structured, multi-threaded C++ app.  If you find one, please let me know.

I offered my recommendations and opinions in the spirit of helpfulness.  I'll let you be the judge of whether our admonitions are overly-dramatic.  I do not have a dog in this fight (I didn't write any part of Boost.Asio or Boost.Thread, though I have a fair amount of experience with each).

As I think this has gotten beyond the scope of Boost.Asio, I plan to refrain from further comment on this subject.  You might have better luck in a broader forum, such as comp.lang.c++, stackoverflow.com, boost-users, etc.  I wish you success in your travels.


Matt



-----Original Message-----
From: kir [mailto:bite.silverfox-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org]
Sent: Sat 5/19/2012 7:41 PM
To: asio-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Subject: Re: [asio-users] thread::interrupt and asio::ios_service::run
 
before too-much-text part. I asked about good way of c