Re: kernel threads

• Subject: Re: kernel threads
• From: Michael George <email@hidden>
• Date: Thu, 5 Dec 2002 10:55:33 -0500

On Thursday, December 5, 2002, at 09:55 AM, Michael George wrote:

On Thursday, December 5, 2002, at 09:38 AM, Jim Magee wrote:

Well... but I want to be able to asynchronously kill it... What is happening is that this thread will start when our device has been idle for a while. That thread will then do Something, and Something can take quite a while (on the order of several ms). It takes long enough that we don't want this happening in our WorkLoop because it will hold all other workloop tasks up. In our case that holdup would be a Very Bad Thing.

But, if while Something is happening our device becomes active again, we want to stop the thread from doing Something and just exit. There are no resources or anything that the thread has to let go (our design is specifically to allow for this thread's activities to be interrupted at any time), it can just die.

If we set a state variable and check it from within the thread (so we'd know when to call IOExitThread()), we'd have to be constantly checking that variable. A bit of a PITA...

The terminate_thread( thread_act_t ) call is still in the system (at least until 10.2.3, eh? :) so there still exists a way to asynchronously kill a thread, it seems. However, how can I turn my IOThread/thread_t into a thread_act_t?

The thread_terminate(thread_act_t) call exists. And you can call it against kernel threads. But threads won't asynchronously terminate while running in kernel mode (they have to wait until they reach a clean point - usually when they are exiting kernel mode and returning to user-level). The thread is marked "aborted" so that any interruptible waits within the kernel will return immediately (so the thread can hurry back to its clean point). But since kernel-resident threads NEVER exit the kernel, they will never reach that particular clean point and notice that they should terminate themselves.

That's just how the kernel works. There's no getting around it. If you look at thread_terminate() code, you'll even see that even it creates an artificial clean-point if the calling thread is kernel resident and terminating itself. But there is no generic mechanism for asynchronously terminating another kernel thread.

You must create your own "clean-point" for kernel-resident threads to notice that they have to exit themselves. Given this, you might as well then just use your own flag that is checked to get you into the clean point, and then have the thread terminate itself. If you need the abort semantic to get you out of prolonged waits, it is available through the thread_abort() and thread_abort_safely() API (which is used by BSD during signal delivery).

• Follow-Ups:
  • Re: kernel threads
    • From: David Gatwood <email@hidden>

• Prev by Date: Re: kernel threads
• Next by Date: Woe is me, can't get the Dec 2002 tools update ...
• Previous by thread: Re: kernel threads
• Next by thread: Re: kernel threads
• Index(es):
  • Date
  • Thread