Deutsch English Français Italiano |
<vljmkl$nh2$1@reader2.panix.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.unix.programmer Subject: Re: OT: Windows (Was: Re: Open Source does not mean easily Date: Tue, 7 Jan 2025 17:01:09 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <vljmkl$nh2$1@reader2.panix.com> References: <uu54la$3su5b$6@dont-email.me> <677c7a1b$0$28501$426a74cc@news.free.fr> <vljbvv$gl9$1@reader2.panix.com> <87ttaa7gay.fsf@doppelsaurus.mobileactivedefense.com> Injection-Date: Tue, 7 Jan 2025 17:01:09 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="24098"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Bytes: 2452 Lines: 38 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.