Re: best approach for multithreading (?)

Kaz Kylheku <643-408-1753@kylheku.com> 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.

Hmm, as long as there is no way to generate signals the above
can be implemented as a no-op or close (say possibly storing
mask somewhere so that application can get it back).  Of
course, it would be harder if Windows has signals or if
POSIX requires ability to generate signals.

--
                              Waldek Hebisch