This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
How to detect that close() in a file handler is called from the signal thread
- From: Gerd dot Spalink at t-online dot de (Gerd Spalink)
- To: "'cygwin-developers at cygwin dot com'" <cygwin-developers at cygwin dot com>
- Date: Sun, 2 May 2004 23:57:48 +0200
- Subject: How to detect that close() in a file handler is called from the signal thread
- Organization: privat
- Reply-to: "Gerd dot Spalink at t-online dot de" <Gerd dot Spalink at t-online dot de>
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