Path: ...!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: OT: Windows (Was: Re: Open Source does not mean easily
Date: Wed, 8 Jan 2025 14:41:22 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vlm2qi$fqs$1@reader2.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <677e2eb8$0$375$426a34cc@news.free.fr> <vllql7$sn6$2@reader2.panix.com> <677e8523$0$28061$426a34cc@news.free.fr>
Injection-Date: Wed, 8 Jan 2025 14:41:22 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="16220"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3591
Lines: 59

In article <677e8523$0$28061$426a34cc@news.free.fr>,
Nicolas George  <nicolas$george@salle-s.org> wrote:
>Dan Cross, dans le message <vllql7$sn6$2@reader2.panix.com>, a écrit :
>> I think it's important to define what you mean when you write,
>> "thread condition."  What, exactly, is that?  Perhaps you mean
>> a condition variable?
>
>Yes, of course that is what “thread condition” means in the context of a
>discussion about POSIX threads.

Not really.  A condition variable is a synchronization
primitive; it is not inherently an attribute of a thread.  When
one phrases it as "thread condition" one gives the impression
that one is talking about some aspect of the thread itself, such
as its state, or the "condition" that it is in, in a similar way
that one might talk about the condition of a patient in a
doctor's office.

As always, in computing, it's better to be precise.

>>			If so, that's true, but I fail to see
>> the relevance: people write multithreaded code that does IO in
>> multiple all the time; there are some techniques that are common
>> for this (Scott alluded to the so-called "pipe trick", due to
>> Bernstein) and some that are less common.
>
>Yes: there are some techniques that are common to implement I/O concurrency
>and that work in the context of threads. You are arguing my point for me:
>the threads did not make implementing the I/O concurrency simpler; quite the
>opposite it they made them harder, as proven by the fact that “techniques”
>had to be deployed.

That's a silly argument.  "Techniques" had to be developed for
literally all of this stuff.

Moreover, things like the self pipe trick are independent of
threads.  That's a "technique" for avoiding races between signal
delivery and "select" etc.  That it can be usefully employed in
a threaded context doesn't say much either for or against
threads.

>POSIX threads do not make I/O concurrency easier, they are not made for
>that, they are for performance.

This is a specious statement that is not backed up by evidence
and is trivially false (two threads can execute blocking "write"
calls on two file descriptors concurrently).

The assertion that POSIX threads are for "performance" deserves
some citation.  POSIX threads might enable one to write parallel
code, thus facilitating higher performance than single-threaded
code, or they might not, depending on the implementation and the
host computer (e.g., if executed on a uniprocessor machine).

Fundamentally, threads are about having multiple control flows
that execute concurrently in a single address space.  That's it,
really.

	- Dan C.