Re: Thread crash in destructor

From: Chris Cleeland (chris.cleeland_at_[hidden])
Date: 2021-10-08 16:45:11

On Fri, Oct 8, 2021 at 1:01 AM Alexander Carôt via Boost-users <
boost-users_at_[hidden]> wrote:

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

You can't set traits on a thread that doesn't exist, regardless of
platform,

Posix APIs offer a way to set up attributes to be applied to a new thread
at thread creation. At first, that's what I thought you were doing, but
when I look at your code, I'm not sure what you're doing.  I don't see a
definitely for `attrs` anywhere in the snippet, but I'm guessing that
`attrs.native_handle()` is supposed to return a `pthread_t` ?  If so, then
your call to pthread_attr_setschedpolicy() doesn't match its
prototype--which takes a pthread_attr_t* as first arg.

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

On linux, sometimes the only way you can actually set priority on a thread
is to set the attributes prior to thread creation and create the thread
that way.  This would be the case if you're using something like `isolcpus`
on your kernel, and the thread doing the creating is running on one of the
isolcpus, because the default behavior is for the new thread to inherit
properties of the parent, and with isolcpus the scheduler doesn't arbitrate
the designated cpus, so the new thread will never get a chance to run and
change its attributes.

-- 
Chris Cleeland