Short answer: don't worry about it; it's an implementation detail and will clean up after itself when your program exits. But if you're curious...
From glibc's timer_create(2)
man page:
SIGEV_THREAD: Upon timer expiration, invoke sigev_notify_function as if it were the start function of a new thread. (Among the implementation possibilities here are that each timer notification could result in the creation of a new thread, or that a single thread is created to receive all notifications.)
And also:
The functionality for SIGEV_THREAD is implemented within glibc, rather than the kernel.
So glibc (i.e. librt.so) assumes that the kernel cannot create a thread in response to a timer event -- that all it supports is sending a signal. So someone needs to receive that signal and create the handler thread. If you wanted to muck with the details of receiving the signal yourself, you wouldn't have used SIGEV_THREAD, so glibc doesn't bother you and instead creates its own thread just for handling timer events.
This timer helper thread lasts from the fist time you call timer_create()
until your program ends. Unless you're doing something unusual, you don't need to worry about it; it will clean up after itself when your program exits. The only thing it does is wait for a timer to expire, so it's not using up any extra processing power. Furthermore, it looks like there will only ever be the one helper thread, no matter how many timers you create.
@jander: Your comment is interesting here "This timer helper thread lasts from the fist time you call timer_create() until your program ends." There are threads created on everytime a timer is timeout. Is this same as the timer_helper_thread() you mention? I have a similar post where I observe a separate thread created only for timer_create(). Would this be the timer_helper_thread()? Ref: New thread on invocation of timer_create()
精彩评论