Re: best approach for multithreading (?)

Liste des GroupesRevenir à cl c  
Sujet : Re: best approach for multithreading (?)
De : chris.m.thomasson.1 (at) *nospam* gmail.com (Chris M. Thomasson)
Groupes : comp.lang.c
Date : 09. Dec 2024, 00:18:42
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vj59gh$2b9v$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : Mozilla Thunderbird
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?

Date Sujet#  Auteur
1 Dec 24 * best approach for multithreading (?)23fir
1 Dec 24 +* Re: best approach for multithreading (?)20candycanearter07
1 Dec 24 i+* Re: best approach for multithreading (?)18Lew Pitcher
1 Dec 24 ii`* Re: best approach for multithreading (?)17Kaz Kylheku
2 Dec 24 ii `* Re: best approach for multithreading (?)16Chris M. Thomasson
3 Dec 24 ii  `* Re: best approach for multithreading (?)15Kaz Kylheku
3 Dec 24 ii   +- Re: best approach for multithreading (?)1Chris M. Thomasson
6 Dec 24 ii   `* Re: best approach for multithreading (?)13James Kuyper
6 Dec 24 ii    +* Re: best approach for multithreading (?)11Kaz Kylheku
6 Dec 24 ii    i+- Re: best approach for multithreading (?)1Kaz Kylheku
7 Dec 24 ii    i`* Re: best approach for multithreading (?)9James Kuyper
7 Dec 24 ii    i +- Re: best approach for multithreading (?)1Chris M. Thomasson
7 Dec 24 ii    i +- Re: best approach for multithreading (?)1Tim Rentsch
8 Dec 24 ii    i `* Re: best approach for multithreading (?)6Kaz Kylheku
8 Dec 24 ii    i  +* Re: best approach for multithreading (?)4Chris M. Thomasson
8 Dec 24 ii    i  i`* Re: best approach for multithreading (?)3Kaz Kylheku
9 Dec 24 ii    i  i +- Re: best approach for multithreading (?)1Chris M. Thomasson
9 Dec 24 ii    i  i `- Re: best approach for multithreading (?)1Chris M. Thomasson
9 Dec 24 ii    i  `- Re: best approach for multithreading (?)1Waldek Hebisch
6 Dec 24 ii    `- Re: best approach for multithreading (?)1Chris M. Thomasson
2 Dec 24 i`- Re: best approach for multithreading (?)1Chris M. Thomasson
2 Dec 24 `* Re: best approach for multithreading (?)2Bonita Montero
3 Dec 24  `- Re: best approach for multithreading (?)1fir

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal