Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #389514

Re: best approach for multithreading (?)

From "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups comp.lang.c
Subject Re: best approach for multithreading (?)
Date 2024-12-07 20:36 -0800
Organization A noiseless patient Spider
Message-ID <vj37o7$3eaf4$4@dont-email.me> (permalink)
References (6 earlier) <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>

Show all headers | View raw


On 12/7/2024 7:49 PM, Kaz Kylheku wrote:
> On 2024-12-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 12/6/24 11:10, Scott Lurndal wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>> On 2024-12-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> ...
>>>>> C <threads.h> can be implemented as a thin wrapper over POSIX threads.
>>>>> The waste is relatively negligible. The differences, were intended to
>>>>> allow <threads.h> to also be implemented on non-POSIX systems as
>>>>> wrappers for whatever the native threading system was.
>>>>
>>>> Generally speaking, you can have a function called pthread_create on
>>>> non-POSIX systems, and a header <pthread.h>.
>>>
>>> There are certain requirements of a posix threads implementation that
>>> might be impossible for a non-POSIX system to implement efficiently;
>>> windows, for example, doesn't support signals.
>>
>> 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?

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

best approach for multithreading (?) fir <profesor.fir@gmail.com> - 2024-11-30 23:04 +0100
  Re: best approach for multithreading (?) candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-01 15:10 +0000
    Re: best approach for multithreading (?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-12-01 15:45 +0000
      Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-01 15:54 +0000
        Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 15:00 -0800
          Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-03 17:48 +0000
            Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-03 12:24 -0800
            Re: best approach for multithreading (?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-05 19:09 -0500
              Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-06 03:14 +0000
                Re: best approach for multithreading (?) scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 16:10 +0000
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-06 18:20 +0000
                Re: best approach for multithreading (?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-07 00:16 -0500
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-06 22:37 -0800
                Re: best approach for multithreading (?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 06:10 -0800
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:49 +0000
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-07 20:36 -0800
                Re: best approach for multithreading (?) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 09:31 +0000
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-08 15:12 -0800
                Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-08 15:18 -0800
                Re: best approach for multithreading (?) antispam@fricas.org (Waldek Hebisch) - 2024-12-09 00:39 +0000
              Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-06 12:14 -0800
    Re: best approach for multithreading (?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 14:59 -0800
  Re: best approach for multithreading (?) Bonita Montero <Bonita.Montero@gmail.com> - 2024-12-02 20:34 +0100
    Re: best approach for multithreading (?) fir <profesor.fir@gmail.com> - 2024-12-03 15:33 +0100

csiph-web