Re: Thread crash in destructor

From: Alexander Carôt (alexander_carot_at_[hidden])
Date: 2021-10-08 06:00:40

> For Win32, you can't call SetThreadPriority like that -- at best, that's 
> doing nothing, at worst, you're changing the priority of some random 
> thread but never the one you intend.  (The attrs.native_handle is not a 
> thread handle.)

Allright, thanks for this additional info thought which comes on top of the crashing issue on OSX. Once we have sorted out why it crashes in the destructor I'd like to get back to this.

 
> You must wait until the thread is actually started before you can set 
> its priority.  Usually the best place to set it is from the thread's 
> method itself.

Is this related to any platform or just WIN32 as you mention above ? In other words: Is my approach of setting the priority fine for OSX and Linux or should it be changed as well ?

Best

Alex

--
http://www.carot.de
Email : Alexander_at_[hidden]
Tel.: [phone]
> Gesendet: Freitag, 08. Oktober 2021 um 00:40 Uhr
> Von: "Gavin Lambert via Boost-users" <boost-users_at_[hidden]>
> An: boost-users_at_[hidden]
> Cc: "Gavin Lambert" <boost_at_[hidden]>
> Betreff: Re: [Boost-users] Thread crash in destructor
>
> On 7/10/2021 22:09, Alexander Carôt wrote:
> > I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX:
> > 
> > #include "test.h"
> > 
> > test::test() {
> >      boost::thread::attributes attrs;
> > 
> >      /// START TRACEROUTE THREAD
> >      #if defined(BOOST_THREAD_PLATFORM_WIN32)
> >          res =
> >          SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL);
> >      #elif defined(BOOST_THREAD_PLATFORM_PTHREAD)
> >          pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO);
> >      #endif
> >      tracerouteThread = boost::thread(
> >          attrs, boost::bind(&test::performTraceroute, this));
> 
> For Win32, you can't call SetThreadPriority like that -- at best, that's 
> doing nothing, at worst, you're changing the priority of some random 
> thread but never the one you intend.  (The attrs.native_handle is not a 
> thread handle.)
> 
> You must wait until the thread is actually started before you can set 
> its priority.  Usually the best place to set it is from the thread's 
> method itself.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>