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 read and write handlers to work concurrently in different
threads.

 

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

 


In the case of composed asynchronous operations, such as
async_read() or async_read_until(), if a completion handler goes through
a strand, then all intermediate handlers should also go through the same
strand. This is needed to ensure thread safe access for any objects that
are shared between the caller and the composed operation (in the case of
async_read() it's the socket, which the caller can close() to cancel the
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-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: 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://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

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+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: 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
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

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 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])
If you ask whether you may call async_read and async_write
simultaneously 
on the same socket, then the answer is yes, of course. 

 

 

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. 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: 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. 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: 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 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: 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, 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: 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
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

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" 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+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

------------------------------------------------------------------------------
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-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+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: 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, 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: 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/
_______________________________________________
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: 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+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: 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 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< at >tycoint.com> wrote:

Define cleanup.  If you mean that you want to try and flush some buffers or something before calling exit(), then I can imagine cases where thread::interrupt() might be helpful.  However, if you mean to shutdown in such a way that would satisfy memory leak checking tools, then you're likely to find that thread::interrupt() leads only down a road of dashed hopes, sorrows, and despair.

I think what Dale means is that because there are blocking calls which thread::interrupt() doesn't cancel, you can have a situation where thread A tears down resources used by thread B, which thread B later tries to use.  This can result in a shutdown which nobody would consider "clean" (i.e. segfault, assertion failure, etc.).

Sorry, but in a non- garbage-collected language, there are no easy answers, nor substitutes for sorting out object ownership & shutdown sequences.


Matt




-----Original Message-----
From: kir
Sent: Thu 5/17/2012 11:51 AM
To: asio-users< at >lists.sourceforge.net
Subject: Re: [asio-users] thread::interrupt and asio::ios_service::run

On Thu, May 17, 2012 at 5:46 PM, Dale Wilson wrote:

which btw is my goal, i use interrupt for controlled cleanup and quit


That is wrong. There are defined cancelation points. If thread avoids
them there is no chance it will be cancelled. Also
boost::thread::interrupt results in exception, not cancellation in
sense of pthread_cancel.

------------------------------------------------------------------------------
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


------------------------------------------------------------------------------
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

 

------------------------------------------------------------------------------
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

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 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-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 cleanup because
in practice i saw several solutions and none of them seemed quite ok.
Most sane are these 3:

1. exit (0)
2. In destructor of each object there is a interrupt/join for each
object's "child" thread (worker thread, event loop thread, etc.)
3. there is a global thread_group which has all current threads, in
main group.interrupt_all is called, then group.join_all is called

way 1 meddles with valgrind (also process may crash with SIGSEGV on FreeBSD)

way 2 leads to unpredictable shutdown time and large amounts of
interrupt/join boilerplate

way 3 requires thread run via wrapper to ensure global thread group is
up to date, requires some cleanup sequences, looks clumsy

when asking my question i wanted to know if there exists proven way
for such seemingly common task as mt app shutdown.

further come comments for your mail, lengthy and perhaps not worth reading

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

i need to
1. stop receiving connections
2. notify current network peers of termination and close sockets
3. store unfinished queries

i need it to be reasonably fast, few seconds


it is very desirable


aren't you over-dramatizing? This is just a function, it works, what
is the problem? It is much simpler to use than pthread_cancel (which
is non-trivial even for C). After all threading library such as
boost::thread should provide mechanism to interrupt its own blocking
calls (mutex::lock, condition::wait, sleep), because there is no way
from outside to do it. And it provides such a call, thread::interrupt.
I don't really understand why you guys are so concerned about its
"inherently broken"  and even "despicable" nature. I am not
boost::thread-orthodox and don't assume it to be canon. But i see no
conceptual flow in thread::interrupt. (and besides if there were so
deep conceptual problems in boost::thread::interrupt or
pthread_cancel, how they happened to stay in respective libraries for
so long?)


These I plan to do all via asio one day. And in asio everything may be
canceled (via stop for  now). From this point of view interrupt is a
proper addition. asio + thread::interrupt make an ideal ecosystem
where everything may be canceled, all io calls automatically become
interruption points. That is why i assumed in my first mail that it is
very natural for io_service to support interrupt.

Also that has nothing to do with thread::interrupt. In such case
valgrind-clean exit may happen only after blocking call finishes. So
it does not illustrate flows in thread::interrupt, more like "example
of mt programming caveats".

In no way i encourage pointless arguing (my problem is long solved)
and i am sure you  know better than me what thread::interrupt can and
can not do. What to Dale his comment was emotionally-driven and mainly
revolved around choosing right epithets and so. Most likely it just
makes no sense.

------------------------------------------------------------------------------
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

------------------------------------------------------------------------------
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