Subject: Re: [linux-audio-dev] How to kill a rogue (p)thread
From: Arve Knudsen (aknuds-1_AT_broadpark.no)
Date: Wed Mar 31 2004 - 21:12:54 EEST
On 31 Mar 2004 11:39:36 -0600, Jack O'Quin <joq_AT_io.com> wrote:
> Arve Knudsen <aknuds-1_AT_broadpark.no> writes:
>
>> True .. That was one approach I considered originally while sketching
>> up solutions, I guess it slipped my mind in the meantime :| I was
>> thinking it could possibly be an expensive operation though as NPTL
>> sources seem to indicate, maybe best avoided if memory locks are
>> involved (I'm no optimization guru, I'm sure you can tell).
>
> It doesn't look all that expensive. The magic is done by a platform-
> dependent compare-and-swap operation. On some SMP machines that can
> be slow, but generally only in high-contention situations (AFAIK).
According to the comments it could involve a memory lock though, wouldnt
this be expensive either way?
>> Anyway, do you think it would be good to keep a canary around to act
>> on CPU starvation?
>
> Personally, I don't see much need for a canary thread. Others may
> disagree. But, a watchdog is quite helpful for debugging. In some
> cases, the application will provide its own watchdog. Is it possible
> for that thread to be optional?
I can see why people might want a canary (a FIFO process eating all CPU
leads to a not so responsive system :/), but it would almost certainly be
the client code hogging CPU. Maybe we could introduce a compile time
conditional, and/or an environment variable (default would be on)? Perhaps
the canary could be conditional as well.
Regards
Arve Knudsen
This archive was generated by hypermail 2b28 : Wed Mar 31 2004 - 21:12:35 EEST