[linux-audio-dev] How to kill a rogue (p)thread

[Arve Knudsen]

On 31 Mar 2004 12:50:53 -0600, Jack O'Quin <joq at io.com> wrote:

>
>> On 31 Mar 2004 11:39:36 -0600, Jack O'Quin <joq at io.com> wrote:
>> > 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).
>
> Arve Knudsen <aknuds-1 at broadpark.no> writes:
>> According to the comments it could involve a memory lock though,
>> wouldnt this be expensive either way?
>
> Dunno.  Depends on the machine implementation.
>
> On the SMP machines I worked with a while back, the cost of a compare
> and swap was about 15 or 20 cycles (IIRC) when the cache line was
> available in the current CPU, but maybe ten times that if there was a
> dirty copy in some other CPU.  These things tend to scale with memory
> and cache latencies more than with CPU speed, so the effect has likely
> become even more pronounced.
>
> For realtime, we need to look at the worst-case, so I guess that can
> be pretty bad.  Still, even the worst case might be acceptable if it
> only happens twice per buffer.
What about pthread_kill with a user defined signal (SIGRTMIN <= sig <= 
SIGRTMAX), where the handler will call pthread_exit? Then the registered 
cleanup functions should be invoked as usual.

>> 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.
>
> I don't see a compile-time option being much use.  PortAudio is a
> shared library, its users will generally all run the same binary.
>
> An environment variable is clumsy, but would work.  Is there any
> mechanism in PA for setting host-dependent options?
Of course I could provide extension functions accepting a PaStream * 
instead, I think it would be a better idea. You would have to include 
pa_linux_alsa.h. Eventually I'm thinking this stuff should be part of the 
common pa_unix utility functions, so an extension for the UNIX 
implementations could be introduced.

Regards

Arve Knudsen