Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: best approach for multithreading (?)
Date: Sun, 8 Dec 2024 15:18:42 -0800
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <vj59gh$2b9v$2@dont-email.me>
References: <ddd3a0b59c95b5752b66f46348c96a6f8279d518@i2pn2.org>
 <slrnvkousf.2d4d7.candycanearter07@candydeb.host.invalid>
 <vii0ao$2jdsb$1@dont-email.me> <20241201074928.161@kylheku.com>
 <viipr8$2qq41$4@dont-email.me> <20241203094647.518@kylheku.com>
 <vitfc3$1so4u$1@dont-email.me> <20241205191339.256@kylheku.com>
 <3mF4P.64$pAh5.41@fx06.iad> <vj0ln4$2se98$1@dont-email.me>
 <20241207044414.446@kylheku.com> <vj37o7$3eaf4$4@dont-email.me>
 <20241208013025.902@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Dec 2024 00:18:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="4ab86222a7b6c89d2f3815566551fac9";
	logging-data="77119"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18N5081DMuwK/z7XixB+CqnGgs/0C0BczQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:eb5rGgvmN/0WHnDncN+uxp0uFeI=
Content-Language: en-US
In-Reply-To: <20241208013025.902@kylheku.com>
Bytes: 2780

On 12/8/2024 1:31 AM, Kaz Kylheku wrote:
> On 2024-12-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 12/7/2024 7:49 PM, Kaz Kylheku wrote:
>>> On 2024-12-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> My words above not-withstanding, I am not in any sense an expert on any
>>>> kind of threading, nor of Windows. What does POSIX require of threads
>>>> with regards to signals?
>>>
>>> Off the top of my head, the highlights:
>>>
>>> - threads have their own signal masks, inherited from the creator which
>>>     calls pthtead_create.
>>> - signal masks can be manipulated so that a given signal will be
>>>     handled in the context of a desired thread.
>>> - sigwait (and several other functions) can be used by a thread to
>>>     wait for one or more signals, allowing signals to be process
>>>     synchronously, somewhat like message passing.
>>>
>>
>> Semaphores are sig safe, so to speak. It's been a while:
>>
>> https://www.man7.org/linux/man-pages/man3/sem_post.3.html
>>
>> should be sig safe? Or, am I wrong here Kaz?
> 
> Yes; just not sem_wait. The obvious idea there is that a signal handler
> is like an interrupt service top half, and those must be able to bang
> semaphores, to wake up something waiting in the bottom half code.
> 

sem_trywait?