How to detect thread kill? - Boost-users - lists.preview.boost.org

newer
Re: [Boost-users] How to detect...

How to detect thread kill?

older
[MultiIndex] cryptic gcc error

Samvel Khalatyan

31 Aug 2011 31 Aug '11

4:03 p.m.

Hi, There is a number of standard ways to interrupt thread from within an application with library tools. However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more? thanks, Samvel.

Attachments:

attachment.html (text/html — 487 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Chris Cleeland

31 Aug 31 Aug

4:52 p.m.

On Wed, Aug 31, 2011 at 11:03 AM, Samvel Khalatyan wrote:

There is a number of standard ways to interrupt thread from within an application with library tools.

Not in a portable fashion.

However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more?

I'm not aware of any consistent way of killing a thread with system tools. Since there is no portable way to do what you're asking, I can't imagine that there's a portable way to detect the effect, either.

Reply

Sign in to reply online Use email software

Samvel Khalatyan

5:19 p.m.

Thank you Chris. I have an application that starts many threads to process input files. The application runs on Linux and sometimes threads get killed. This leads to segmentation faults and termination without memory clean-up, etc. So, I thought of the way to at least catch such cases and cleanly quit the application. Samvel. On Wed, Aug 31, 2011 at 11:52 AM, Chris Cleeland wrote:

On Wed, Aug 31, 2011 at 11:03 AM, Samvel Khalatyan wrote:

...
There is a number of standard ways to interrupt thread from within an application with library tools.

Not in a portable fashion.

...
However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more?

I'm not aware of any consistent way of killing a thread with system tools.

Since there is no portable way to do what you're asking, I can't imagine that there's a portable way to detect the effect, either. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Reply

Sign in to reply online Use email software

Rune Lund Olesen

8:32 p.m.

You could make a structure on the heap to track which threads you kill yourself and which you think is alive - i imagine. Each thread should then update said structure when done (in a threadsafe way needless to say). If a thread then is gone and your tracker thinks its alive you can conclude something else killed it -almost in a portable way i guess. Regards On Wed, Aug 31, 2011 at 7:19 PM, Samvel Khalatyan wrote:

Thank you Chris. I have an application that starts many threads to process input files. The application runs on Linux and sometimes threads get killed. This leads to segmentation faults and termination without memory clean-up, etc. So, I thought of the way to at least catch such cases and cleanly quit the application. Samvel. On Wed, Aug 31, 2011 at 11:52 AM, Chris Cleeland wrote:

...
On Wed, Aug 31, 2011 at 11:03 AM, Samvel Khalatyan wrote:

...
There is a number of standard ways to interrupt thread from within an application with library tools.

Not in a portable fashion.

...
However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more?

I'm not aware of any consistent way of killing a thread with system tools.

Since there is no portable way to do what you're asking, I can't imagine that there's a portable way to detect the effect, either. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Reply

Sign in to reply online Use email software

Samvel Khalatyan

2 Sep 2 Sep

3:21 p.m.

Dear Rune, Thanks for the trick. However, this solution may lead to some sort of extra delay, b/c manager of the threads has to wait for certain time before it can make assumption that thread was killed. I am looking for the "catch-kill" solution. Regards On Wed, Aug 31, 2011 at 3:32 PM, Rune Lund Olesen wrote:

You could make a structure on the heap to track which threads you kill yourself and which you think is alive - i imagine. Each thread should then update said structure when done (in a threadsafe way needless to say). If a thread then is gone and your tracker thinks its alive you can conclude something else killed it -almost in a portable way i guess.

Regards

On Wed, Aug 31, 2011 at 7:19 PM, Samvel Khalatyan wrote:

...
Thank you Chris. I have an application that starts many threads to process input files. The application runs on Linux and sometimes threads get killed. This leads to segmentation faults and termination without memory clean-up, etc. So, I thought of the way to at least catch such cases and cleanly quit the application. Samvel. On Wed, Aug 31, 2011 at 11:52 AM, Chris Cleeland < chris.cleeland@gmail.com> wrote:

...
On Wed, Aug 31, 2011 at 11:03 AM, Samvel Khalatyan wrote:

...
There is a number of standard ways to interrupt thread from within an application with library tools.

Not in a portable fashion.

...
However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more?

I'm not aware of any consistent way of killing a thread with system

tools.

...
Since there is no portable way to do what you're asking, I can't imagine that there's a portable way to detect the effect, either. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Reply

Sign in to reply online Use email software

Chris Cleeland

31 Aug 31 Aug

8:56 p.m.

On Wed, Aug 31, 2011 at 12:19 PM, Samvel Khalatyan wrote:

I have an application that starts many threads to process input files. The application runs on Linux and sometimes threads get killed. This leads to segmentation faults and termination without memory clean-up, etc. So, I thought of the way to at least catch such cases and cleanly quit the application.

How are these threads getting killed? Are you sure they're not hitting a situation where they're getting a signal?

Reply

Sign in to reply online Use email software

Samvel Khalatyan

2 Sep 2 Sep

3:24 p.m.

Hi Chris, I guess you are right: the whole process is killed with all thread from Linux command line. I suppose, there is no way to kill single thread. Regards On Wed, Aug 31, 2011 at 3:56 PM, Chris Cleeland wrote:

On Wed, Aug 31, 2011 at 12:19 PM, Samvel Khalatyan wrote:

...
I have an application that starts many threads to process input files. The application runs on Linux and sometimes threads get killed. This leads to segmentation faults and termination without memory clean-up, etc. So, I thought of the way to at least catch such cases and cleanly quit the application.

How are these threads getting killed? Are you sure they're not hitting a situation where they're getting a signal? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Reply

Sign in to reply online Use email software

Chris Cleeland

3:36 p.m.

On Fri, Sep 2, 2011 at 10:24 AM, Samvel Khalatyan wrote:

I guess you are right: the whole process is killed with all thread from Linux command line. I suppose, there is no way to kill single thread.

Not from the command line. pthread_kill() can direct a signal to a specific thread, but only from within the process that hosts the thread. The "pthreads primer" and "Programming Pthreads" books have some reasonable discussions on mixing signals and threads. Beware that they don't mix well.

Reply

Sign in to reply online Use email software

4922

Age (days ago)

4924

Last active (days ago)

Download

7 comments

3 participants

tags

participants (3)

Chris Cleeland
Rune Lund Olesen
Samvel Khalatyan