Re: How to detect that close() in a file handler is called from the signal thread

[Christopher Faylor <cgf at alum dot bu dot edu>]

On Sun, May 02, 2004 at 11:57:48PM +0200, Gerd Spalink wrote:
>It has been reported to me that /dev/dsp does not respond properly to
>interruptions by Ctrl-C.  The problem is that it tries to flush the
>audio-play buffer normally, that means it sleeps until all audio has
>been played.
>
>I found that after Ctrl-C, close() of the fhandler is called from the
>signal thread.  /dev/dsp's close() then blocks the signal thread, and
>we even get priority inversion: The main thread continues to run.

The only time the signal thread closes anything is when it is calling
close_all_handles prior to exiting.  It's not just the signal thread
that calls this, though.  Any thread can call exit().

>In order to correctly emulate /dev/dsp, inside the fhandler's
>close() we need two different behaviors:
>
>1. Normal close: Wait until all audio has been played,
>                 clean up, then return
>
>2. Ctrl-C close: Discard all pending audio, clean up, return
>      (and make sure the situation where the main thread is
>       stuck in write() waiting for audio buffers is handled
>       correctly)
>
>Question: How should I detect the Ctrl-C condition?
>  (both of the following should work somehow)
>
>a) GetCurrentThreadId () != cygthread::main_thread_id
>   (will create a mess for multi-threaded audio applications)
>
>b) strcmp("sig",cygthread::name ()) == 0
>   (I would prefer to check for the signal thread by ID
>    rather than by name)
>
>Does anyone have a better idea?

If you were checking for the signal thread, the check would be

  if (GetCurrentThreadId () == sigtid)

But, i think what you really want to check for is:

 if (exit_state)

cgf