kir [mailto:bite.silverfox@gmail.com<= /A>]<BR>
1970-01-01 00:00:00 UTC
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
------_=_NextPart_001_01CD364D.4A8F1AE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [asio-users] thread::interrupt and asio::ios_service::run</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>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.<BR>
<BR>
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).<BR>
<BR>
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.<BR>
<BR>
<BR>
Matt<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: kir [<A HREF="mailto:***@gmail.com">mailto:***@gmail.com</A>]<BR>
Sent: Sat 5/19/2012 7:41 PM<BR>
To: asio-***@lists.sourceforge.net<BR>
Subject: Re: [asio-users] thread::interrupt and asio::ios_service::run<BR>
<BR>
before too-much-text part. I asked about good way of cleanup because<BR>
in practice i saw several solutions and none of them seemed quite ok.<BR>
Most sane are these 3:<BR>
<BR>
1. exit (0)<BR>
2. In destructor of each object there is a interrupt/join for each<BR>
object's "child" thread (worker thread, event loop thread, etc.)<BR>
3. there is a global thread_group which has all current threads, in<BR>
main group.interrupt_all is called, then group.join_all is called<BR>
<BR>
way 1 meddles with valgrind (also process may crash with SIGSEGV on FreeBSD)<BR>
<BR>
way 2 leads to unpredictable shutdown time and large amounts of<BR>
interrupt/join boilerplate<BR>
<BR>
way 3 requires thread run via wrapper to ensure global thread group is<BR>
up to date, requires some cleanup sequences, looks clumsy<BR>
<BR>
when asking my question i wanted to know if there exists proven way<BR>
for such seemingly common task as mt app shutdown.<BR>
<BR>
further come comments for your mail, lengthy and perhaps not worth reading<BR>
<BR>
On Sat, May 19, 2012 at 9:04 AM, Gruenke, Matt <***@tycoint.com> wrote:<BR>
> Define cleanup.<BR>
<BR>
i need to<BR>
1. stop receiving connections<BR>
2. notify current network peers of termination and close sockets<BR>
3. store unfinished queries<BR>
<BR>
i need it to be reasonably fast, few seconds<BR>
<BR>
> However, if you mean to shutdown in<BR>
> such a way that would satisfy memory leak checking tools,<BR>
<BR>
it is very desirable<BR>
<BR>
> then you're likely<BR>
> to find that thread::interrupt() leads only down a road of dashed hopes,<BR>
> sorrows, and despair.<BR>
<BR>
aren't you over-dramatizing? This is just a function, it works, what<BR>
is the problem? It is much simpler to use than pthread_cancel (which<BR>
is non-trivial even for C). After all threading library such as<BR>
boost::thread should provide mechanism to interrupt its own blocking<BR>
calls (mutex::lock, condition::wait, sleep), because there is no way<BR>
from outside to do it. And it provides such a call, thread::interrupt.<BR>
I don't really understand why you guys are so concerned about its<BR>
"inherently broken" and even "despicable" nature. I am not<BR>
boost::thread-orthodox and don't assume it to be canon. But i see no<BR>
conceptual flow in thread::interrupt. (and besides if there were so<BR>
deep conceptual problems in boost::thread::interrupt or<BR>
pthread_cancel, how they happened to stay in respective libraries for<BR>
so long?)<BR>
<BR>
> I think what Dale means is that because there are blocking calls which<BR>
> thread::interrupt() doesn't cancel<BR>
<BR>
These I plan to do all via asio one day. And in asio everything may be<BR>
canceled (via stop for now).
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
------_=_NextPart_001_01CD364D.4A8F1AE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [asio-users] thread::interrupt and asio::ios_service::run</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>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.<BR>
<BR>
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).<BR>
<BR>
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.<BR>
<BR>
<BR>
Matt<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: kir [<A HREF="mailto:***@gmail.com">mailto:***@gmail.com</A>]<BR>
Sent: Sat 5/19/2012 7:41 PM<BR>
To: asio-***@lists.sourceforge.net<BR>
Subject: Re: [asio-users] thread::interrupt and asio::ios_service::run<BR>
<BR>
before too-much-text part. I asked about good way of cleanup because<BR>
in practice i saw several solutions and none of them seemed quite ok.<BR>
Most sane are these 3:<BR>
<BR>
1. exit (0)<BR>
2. In destructor of each object there is a interrupt/join for each<BR>
object's "child" thread (worker thread, event loop thread, etc.)<BR>
3. there is a global thread_group which has all current threads, in<BR>
main group.interrupt_all is called, then group.join_all is called<BR>
<BR>
way 1 meddles with valgrind (also process may crash with SIGSEGV on FreeBSD)<BR>
<BR>
way 2 leads to unpredictable shutdown time and large amounts of<BR>
interrupt/join boilerplate<BR>
<BR>
way 3 requires thread run via wrapper to ensure global thread group is<BR>
up to date, requires some cleanup sequences, looks clumsy<BR>
<BR>
when asking my question i wanted to know if there exists proven way<BR>
for such seemingly common task as mt app shutdown.<BR>
<BR>
further come comments for your mail, lengthy and perhaps not worth reading<BR>
<BR>
On Sat, May 19, 2012 at 9:04 AM, Gruenke, Matt <***@tycoint.com> wrote:<BR>
> Define cleanup.<BR>
<BR>
i need to<BR>
1. stop receiving connections<BR>
2. notify current network peers of termination and close sockets<BR>
3. store unfinished queries<BR>
<BR>
i need it to be reasonably fast, few seconds<BR>
<BR>
> However, if you mean to shutdown in<BR>
> such a way that would satisfy memory leak checking tools,<BR>
<BR>
it is very desirable<BR>
<BR>
> then you're likely<BR>
> to find that thread::interrupt() leads only down a road of dashed hopes,<BR>
> sorrows, and despair.<BR>
<BR>
aren't you over-dramatizing? This is just a function, it works, what<BR>
is the problem? It is much simpler to use than pthread_cancel (which<BR>
is non-trivial even for C). After all threading library such as<BR>
boost::thread should provide mechanism to interrupt its own blocking<BR>
calls (mutex::lock, condition::wait, sleep), because there is no way<BR>
from outside to do it. And it provides such a call, thread::interrupt.<BR>
I don't really understand why you guys are so concerned about its<BR>
"inherently broken" and even "despicable" nature. I am not<BR>
boost::thread-orthodox and don't assume it to be canon. But i see no<BR>
conceptual flow in thread::interrupt. (and besides if there were so<BR>
deep conceptual problems in boost::thread::interrupt or<BR>
pthread_cancel, how they happened to stay in respective libraries for<BR>
so long?)<BR>
<BR>
> I think what Dale means is that because there are blocking calls which<BR>
> thread::interrupt() doesn't cancel<BR>
<BR>
These I plan to do all via asio one day. And in asio everything may be<BR>
canceled (via stop for now).