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

[Gerd Spalink]

Hello,

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.

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?

Thanks

Gerd Spalink