Re: OT: Windows (Was: Re: Open Source does not mean easily

In article <87ttaa7gay.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat  <rweikusat@talktalk.net> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
[...]
>

there is no reason you cannot, say, have a signal handler that
broadcasts on a condition variable after an asynchronous IO operation
completes, thus waking up a thread.

>
The pthread_cond_* calls are not async-signal safe and hence, this is
either undefined behaviour (newly introduced with POSIX.1-2024) or
undefined behaviour if the signal handler interrupted something that
isn't async-signal safe (prior to POSIX.1-2024 and still retained in the
current text).

You are correct; I was wrong about condvars.  From:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_broadcast.html

|It is not safe to use the pthread_cond_signal() function in a
|signal handler that is invoked asynchronously. Even if it were
|safe, there would still be a race between the test of the
|Boolean pthread_cond_wait() that could not be efficiently
|eliminated.
|
|Mutexes and condition variables are thus not suitable for
|releasing a waiting thread by signaling from code running in a
|signal handler.

(Curiously they make no mention of `pthread_cond_broadcast`
here; I suppose the same rationale applies.)

However, POSIX semaphores can safely be used for that.

Another mechanism might be to have a thread blocked in `sigwait`
or `sigtimedwait` and use `pthread_kill` to signal it.

- Dan C.