Thread pool and context alloc/free with 6.1

When I try to shutdown the threads from my thread pool (using a list of
active thread IDs and pthread_cancel()'ing each of them), it appears as
though the thread pool tries to allocate and de-allocate a context for a
thread with a thread ID of 1 which I thought would be my main thread of
execution. Am I wrong in this assumption? Is there another way of “stopping”
a thread pool?

You probably want to take a look at the thread_pool_destroy() function.
It was not fully there in 6.0, but in 6.1 it should be able to shutdown
you thread pool for you.

-Peter

Brian Meinke <RoverFan@chartermi.net> wrote:

When I try to shutdown the threads from my thread pool (using a list of
active thread IDs and pthread_cancel()'ing each of them), it appears as
though the thread pool tries to allocate and de-allocate a context for a
thread with a thread ID of 1 which I thought would be my main thread of
execution. Am I wrong in this assumption? Is there another way of “stopping”
a thread pool?

Thanks for the reply. After some more investigation last night, it is the
call to thread_pool_destroy that causes a call to the context
allocator/de-allocator for thread 1. I’ve tried using thread_pool_control to
set the thread pool limits to a maximum of 1 thread…no luck.


<pgraves@qnx.com> wrote in message news:9m5gun$50v$1@nntp.qnx.com

You probably want to take a look at the thread_pool_destroy() function.
It was not fully there in 6.0, but in 6.1 it should be able to shutdown
you thread pool for you.

-Peter

Brian Meinke <> RoverFan@chartermi.net> > wrote:
When I try to shutdown the threads from my thread pool (using a list of
active thread IDs and pthread_cancel()'ing each of them), it appears as
though the thread pool tries to allocate and de-allocate a context for a
thread with a thread ID of 1 which I thought would be my main thread of
execution. Am I wrong in this assumption? Is there another way of
“stopping”
a thread pool?

Brian Meinke <RoverFan@chartermi.net> wrote:
: Thanks for the reply. After some more investigation last night, it is the
: call to thread_pool_destroy that causes a call to the context
: allocator/de-allocator for thread 1. I’ve tried using thread_pool_control to
: set the thread pool limits to a maximum of 1 thread…no luck.

I think it is creating a dummy context in which to unblock any waiting
pool threads and cause them to exit cleanly. Ensure that you have set
up the “unblock_func” field of the pool configuration (to something
other than NULL, try “_message_unblock()”, although I have never had
success with that personally, instead I install a custom function which
raises an invalid pulse on myself).

That appears to be correct. After installing an unblock handler for the
thread pool, it gets called once for each thread in the pool. The thread ID
of the thread in which the unblock handler runs is thread 1. Thanks for the
help

“John Garvey” <jgarvey@qnx.com> wrote in message
news:9m5lji$8b1$1@nntp.qnx.com

Brian Meinke <> RoverFan@chartermi.net> > wrote:
: Thanks for the reply. After some more investigation last night, it is
the
: call to thread_pool_destroy that causes a call to the context
: allocator/de-allocator for thread 1. I’ve tried using
thread_pool_control to
: set the thread pool limits to a maximum of 1 thread…no luck.

I think it is creating a dummy context in which to unblock any waiting
pool threads and cause them to exit cleanly. Ensure that you have set
up the “unblock_func” field of the pool configuration (to something
other than NULL, try “_message_unblock()”, although I have never had
success with that personally, instead I install a custom function which
raises an invalid pulse on myself).