Re: best approach for multithreading (?)

Liste des GroupesRevenir à cl c  
Sujet : Re: best approach for multithreading (?)
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.c
Date : 03. Dec 2024, 18:48:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241203094647.518@kylheku.com>
References : 1 2 3 4 5
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-12-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 12/1/2024 7:54 AM, Kaz Kylheku wrote:
On 2024-12-01, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
On Sun, 01 Dec 2024 15:10:03 +0000, candycanearter07 wrote:
There's a standard library for multithreading.
https://www.man7.org/linux/man-pages/man7/pthreads.7.html
>
Since C11, the C standard library has provided it's own support for
threading, which (I'm told) closely resembles the POSIX threading
model implemented in the Linux pthreads library.
 
Yes; they stupidly took a chunk of POSIX (IEE 1003 standard, originally
formed as a fork of C to standarize Unix things) and cloned an
incompatible version with different types and function names.
 
For over a decade before that, people were already using POSIX threads
on platforms that don't have POSIX threads, via libraries.
>
Here is one I used to always use back in the day over on Windows:
>
https://sourceware.org/pthreads-win32/

And that is not significantly harder to implement (if at all) than C11
threading.

Think about it. The POSIX standard includes ISO C by reference.
So that means POSIX has to have two thread libraries.
It's a waste of flash in embedded systems.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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