On Tue, 7 Jan 2025 15:56:46 -0000 (UTC), Muttley wrote:

> On 07 Jan 2025 15:54:48 GMT Nicolas George <nicolas$george@salle-s.org>
> wibbled:
>
>>I tried, and stopped trying using threads for I/O concurrency.
>
> For some mad reason it seems to be the way to do it in Windows and also
> Java IIRC.

Remember the era: it was the 1990s, when threads were still a new thing to
PC OSes, and they were considered the best way to do everything involving
nondeterminism, including GUIs.

On 07 Jan 2025 08:59:28 GMT, Nicolas George wrote:

> Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
> écrit :
>>
>> Linux offers signalfd, so you can indeed use poll(2) in a thread to be
>> woken up by any file descriptor, including a signal one (and that
>> includes POSIX real-time signals).
>
> Proving my point that you need to use poll() even when doing threads.

But you said “it is not possible to poll() on a thread condition”, when it
fact such usage is commonplace, as I pointed out.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On 07 Jan 2025 08:59:28 GMT, Nicolas George wrote:
>
>> Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
>> écrit :
>>>
>>> Linux offers signalfd, so you can indeed use poll(2) in a thread to be
>>> woken up by any file descriptor, including a signal one (and that
>>> includes POSIX real-time signals).
>>
>> Proving my point that you need to use poll() even when doing threads.
>
>But you said “it is not possible to poll() on a thread condition”, when it
>fact such usage is commonplace, as I pointed out.

It is perfectly possible to poll() on a thread condition. See pipe(2).

Scott Lurndal, dans le message <BcmfP.289889$aTp4.50420@fx09.iad>, a
écrit :
> It is perfectly possible to poll() on a thread condition. See pipe(2).

It is possible to write code to wake a thread blocked in poll(). I have not
tried to deny this. It is not possible to poll() directly on a thread
condition. You have not disproved that.

On Tue, 7 Jan 2025 17:19:56 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vljmc6$29tkd$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Tue, 7 Jan 2025 16:02:51 -0000 (UTC)
>>>In the kernel, it sure is. Unix programmers have been writing
>>>asynchronous programs (using e.g. `fork`) since 1970.
>>
>>Thats not what we're discussion here and you know it.
>
>Actually, it is.

Ah ok, goalposts moved. Why not some straw men while you're at it?

>>>https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
>>
>>Basically sets flags.
>
>Did you actually read and understand any of that code?

Did you?

>>
>>Not a clever way to do it because an xterm and other terminal progs can
>>indirectly cause a whole load of SIGWINCH to be created if someone is
>resizing
>>it and only the final one really needs the ioctl call done. Better to set a
>>flag then manually do a call when appropriate.
>
>Ok. You may even be right! But tell me: where would you check
>those flags?

Presuably a genius like you would know most terminal programs have a seperate
thread or a multiplex timeout in order to flash the cursor. You work out
the rest.

>Regardless, here you are, again, moving the goalposts in the
>face of evidence that contradicted your earlier position.

Irony, love it.

>>There are always exceptions to every rule. You seem to be so desperate to
>>win this argument I can only assume your fragile ego has been burst by
>>someone having the temerity to disagree with you. Tough, suck it up.
>
>Ah, here we go. The classic attempt at an insult.

If the shoe fits.

>Look, you made categorical, definitive statements. Those
>statements were factually incorrect. I pointed that out. You

No, I stated the majority approach to using signals. You disagree which is
fine, but don't pretent your view is THE view, it isn't.

>Perhaps I am not the one with the fragile ego that needs to suck
>it up when disagreed with.

Ego size on usenet is almost always correlated with the verbiage of a reply.

On Tue, 7 Jan 2025 17:23:01 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vljmlt$29vt3$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Tue, 7 Jan 2025 16:10:55 -0000 (UTC)
>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>Nope, I like my relative anonymity here and I don't need to prove anything to
>>some twat with a chip on his shoulder getting worked up over technical trivia.
>
>
>Ok. So we're just supposed to take your word for it, I guess.
>Got it.

In one.

>>Believe what you like, I couldn't give a rats arse.
>
>You also have no evidence to back up your claims, it seems.

Plenty of evidence out there.

>>Am I supposed to be impressed?
>
>*shrug* I think my credentials speak for themselves. I really
>don't care whether you're impressed or not.

What credentials? You work for some neverheardofit software house and have
mostly done a load of forks of other peoples code. Standard dev stuff, nothing
special.

On Tue, 07 Jan 2025 19:09:53 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <vGbfP.54357$XfF8.7280@fx04.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>
>
>>>Applications in those days (e.g. fsck) would access the
>>>raw character device using the unbuffered read() and
>>>write() system calls rather than using stdio. A key
>>>characteristic of raw devices were that the hardware DMA would
>>>use the application buffer directly rather than copying
>>>the data to the kernel buffer pool first.
>>
>>They still do!
>
>Well, not on linux. Even O_DIRECT still goes through
>the file cache, last I checked.
>
>I submitted a 'raw device' patch to the linux mailing
>list in the late 90s while at SGI. It wasn't accepted because
>O_DIRECT was considered sufficient, even with the spurious
>copy. The overhead of pinning the user space pages was
>considered onerous.

I vaguely remember Oracle complaining about this back in the day meaning
they couldn't guarantee their RDBMS transaction writes on Linux. Not sure
if or when it was solved.

On Wed, 8 Jan 2025 02:36:01 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Tue, 7 Jan 2025 15:56:46 -0000 (UTC), Muttley wrote:
>
>> On 07 Jan 2025 15:54:48 GMT Nicolas George <nicolas$george@salle-s.org>
>> wibbled:
>>
>>>I tried, and stopped trying using threads for I/O concurrency.
>>
>> For some mad reason it seems to be the way to do it in Windows and also
>> Java IIRC.
>
>Remember the era: it was the 1990s, when threads were still a new thing to
>PC OSes, and they were considered the best way to do everything involving
>nondeterminism, including GUIs.

Unfortunately there are still far to many programmers around for whom threads
are their go to hammer no matter what problem they're trying to solve.

In article <vllcml$2mqb8$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Tue, 7 Jan 2025 17:23:01 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vljmlt$29vt3$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>>On Tue, 7 Jan 2025 16:10:55 -0000 (UTC)
>>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>>Nope, I like my relative anonymity here and I don't need to prove anything to
>>>some twat with a chip on his shoulder getting worked up over technical trivia.
>>
>>
>>Ok. So we're just supposed to take your word for it, I guess.
>>Got it.
>
>In one.
>
>>>Believe what you like, I couldn't give a rats arse.
>>
>>You also have no evidence to back up your claims, it seems.
>
>Plenty of evidence out there.

Plenty of contradictory evidence, you mean.

>>>Am I supposed to be impressed?
>>
>>*shrug* I think my credentials speak for themselves. I really
>>don't care whether you're impressed or not.
>
>What credentials? You work for some neverheardofit software house and have
>mostly done a load of forks of other peoples code. Standard dev stuff, nothing
>special.

Yeah, ok, sure.

- Dan C.

In article <677e2eb8$0$375$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
>Scott Lurndal, dans le message <BcmfP.289889$aTp4.50420@fx09.iad>, a
> �crit�:
>> It is perfectly possible to poll() on a thread condition. See pipe(2).
>
>It is possible to write code to wake a thread blocked in poll(). I have not
>tried to deny this. It is not possible to poll() directly on a thread
>condition. You have not disproved that.

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? 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. It may be harder or
easier depending on which techniques you employ, but it's all
doable.

- Dan C.

In article <vllcgq$2mphu$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Tue, 7 Jan 2025 17:19:56 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vljmc6$29tkd$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>>On Tue, 7 Jan 2025 16:02:51 -0000 (UTC)
>>>>In the kernel, it sure is. Unix programmers have been writing
>>>>asynchronous programs (using e.g. `fork`) since 1970.
>>>
>>>Thats not what we're discussion here and you know it.
>>
>>Actually, it is.
>
>Ah ok, goalposts moved. Why not some straw men while you're at it?
>
>>>>https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
>>>
>>>Basically sets flags.
>>
>>Did you actually read and understand any of that code?
>
>Did you?

Yes. I see that the call chains invoked from that handler wind
up calling things like `malloc`. I guess you couldn't read the
code well enough to see that for yourself.

>>>Not a clever way to do it because an xterm and other terminal progs can
>>>indirectly cause a whole load of SIGWINCH to be created if someone is
>>resizing
>>>it and only the final one really needs the ioctl call done. Better to set a
>>>flag then manually do a call when appropriate.
>>
>>Ok. You may even be right! But tell me: where would you check
>>those flags?
>
>Presuably a genius like you would know most terminal programs have a seperate
>thread or a multiplex timeout in order to flash the cursor. You work out
>the rest.

Right, handwave away those very real concerns. We're talking
about Unix here, not code running on some microcontroller; code
might be sitting in some tight loop doing computation for
arbitrarily long.

>>Regardless, here you are, again, moving the goalposts in the
>>face of evidence that contradicted your earlier position.
>
>Irony, love it.
>
>>>There are always exceptions to every rule. You seem to be so desperate to
>>>win this argument I can only assume your fragile ego has been burst by
>>>someone having the temerity to disagree with you. Tough, suck it up.
>>
>>Ah, here we go. The classic attempt at an insult.
>
>If the shoe fits.
>
>>Look, you made categorical, definitive statements. Those
>>statements were factually incorrect. I pointed that out. You
>
>No, I stated the majority approach to using signals. You disagree which is
>fine, but don't pretent your view is THE view, it isn't.

Bluntly, I don't see any evidence that you are qualified enough
to make any statement regarding the "majority approach" to,
well, just about anything related to the domain, let alone the
industry writ large. On the other hand, despite you assuring us
that we should just take your word for it that you're some kind
of expert, I see plenty of evidence in the form of factually
incorrect statements to conclude that you don't know what you're
about generally.

In other words, no, I'm not just taking your word for it, but
instead trusting the evidence before me.

>>Perhaps I am not the one with the fragile ego that needs to suck
>>it up when disagreed with.
>
>Ego size on usenet is almost always correlated with the verbiage of a reply.

I'm not the one who started with dishing out insults at the
first person who disagreed with me.

Feel free to have the last word, but absent some actually
technical point, I'm done with you.

- Dan C.

On Wed, 8 Jan 2025 12:19:13 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vllcml$2mqb8$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Tue, 7 Jan 2025 17:23:01 -0000 (UTC)
>>>You also have no evidence to back up your claims, it seems.
>>
>>Plenty of evidence out there.
>
>Plenty of contradictory evidence, you mean.

Probably for both methods.

>>What credentials? You work for some neverheardofit software house and have
>>mostly done a load of forks of other peoples code. Standard dev stuff, nothing
>
>>special.
>
>Yeah, ok, sure.

Hacking other peoples code doesn't impress me. They've done all the hard work.

On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vllcgq$2mphu$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Tue, 7 Jan 2025 17:19:56 -0000 (UTC)
>>Presuably a genius like you would know most terminal programs have a seperate
>>thread or a multiplex timeout in order to flash the cursor. You work out
>>the rest.
>
>Right, handwave away those very real concerns. We're talking
>about Unix here, not code running on some microcontroller; code

Oops, awkward fact avoided eh? :)

And you don't think microcontrollers can run linux with X on top?

>>No, I stated the majority approach to using signals. You disagree which is
>>fine, but don't pretent your view is THE view, it isn't.
>
>Bluntly, I don't see any evidence that you are qualified enough
>to make any statement regarding the "majority approach" to,

I don't need to prove myself to argue with some random troll on a newsgroup.
If you can't handle that thats your problem, not mine.

>>Ego size on usenet is almost always correlated with the verbiage of a reply.
>
>I'm not the one who started with dishing out insults at the
>first person who disagreed with me.

Define insult. However here's one: you're clearly a thin skinned snowflake.

>Feel free to have the last word, but absent some actually
>technical point, I'm done with you.

Suits me mate.

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.

> 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.

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

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.

On 08 Jan 2025 14:01:07 GMT
Nicolas George <nicolas$george@salle-s.org> wibbled:
>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.

No, they're called condition variables, not thread conditions which implies
something rather different. Surely an experienced genius like you would know
that.

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

Not really. They're made for multitasking in situations where multiplexing
would be too complicated or impossible and multiprocess would be overkill or
too resource intensive. On a single core CPU using threads could actually slow
a program down compared to using a single thread.

Muttley@DastardlyHQ.org writes:
>On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)

>
>I don't need to prove myself to argue with some random troll on a newsgroup.
>If you can't handle that thats your problem, not mine.

Look in the mirror, nameless troll.

Dan is well known and respected in the Unix world. You, not so much.

scott@slp53.sl.home (Scott Lurndal) writes:

> Muttley@DastardlyHQ.org writes:
>
>> On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
>> [...]
>> I don't need to prove myself to argue with some random troll on a
>> newsgroup. If you can't handle that thats your problem, not mine.
>
> Look in the mirror, nameless troll. [...]

If you wouldn't mind a question, I'm wondering why you continue
to take the bait.

In article <ZmxfP.284330$Uup4.225209@fx10.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Dan is well known and respected in the Unix world. You, not so much.

Thank you, Scott.

- Dan C.

On 2025-01-08, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
> I don't need to prove myself to argue with some random troll on a newsgroup.
> If you can't handle that thats your problem, not mine.

I have to say, that's pretty tone deaf, as a reply to Dan Cross.

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

On Wed, 8 Jan 2025 08:26:06 -0000 (UTC), Muttley wrote:

> I vaguely remember Oracle complaining about this back in the day meaning
> they couldn't guarantee their RDBMS transaction writes on Linux.

Blame the hard drive vendors for putting stupid caches on their drives.
It’s not a Linux-specific problem.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sat, 04 Jan 2025 19:17:15 -0300, Salvador Mirzo wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> Windows NT was masterminded by Dave Cutler ...
>>
>> Is that Dave with a YouTube channel?
>
> No, that’s a different former Microsoftie, but he has had Cutler on his
> channel for an extended interview.
>
> I found it ironic that there was a PiDP-11, I think it was, placed within
> arm’s reach behind the guy during the entire interview. You know, the
> PDP-11 emulator that runs on a Linux-based Raspberry Pi. I wonder if the
> Unix-hater ever noticed that ...

LOL. Can you find a link to this interview? Sounded very interesting.

--
Thanks!

On Wed, 08 Jan 2025 16:05:13 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
>Muttley@DastardlyHQ.org writes:
>>On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
>
>>
>>I don't need to prove myself to argue with some random troll on a newsgroup.
>>If you can't handle that thats your problem, not mine.
>
>Look in the mirror, nameless troll.

The usual "i don't agree with you so you must be a troll" attitude.

>
>Dan is well known and respected in the Unix world. You, not so much.

Is he? Never heard of him until recently. What exactly has he done thats
so impressive? His github certainly gives no clue. Lots of forks of other
peoples stuff. BFD.

On Wed, 8 Jan 2025 20:27:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:
>On 2025-01-08, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
>> I don't need to prove myself to argue with some random troll on a newsgroup.
>> If you can't handle that thats your problem, not mine.
>
>I have to say, that's pretty tone deaf, as a reply to Dan Cross.

Sorry if I don't hero worship like you. If I think someone's talking bollocks
then I'll call it out.

On 2025-01-15, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
> The usual "i don't agree with you so you must be a troll" attitude.

Rather, it is this accusation that is an extremely common trope.
Rarely is it true.

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