Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399861 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-06-10 13:53 +0200 |
| Last post | 2026-06-17 12:11 -0700 |
| Articles | 20 on this page of 100 — 12 participants |
Back to article view | Back to comp.lang.c
acquire + sleep + async fir <profesor.fir@gmail.com> - 2026-06-10 13:53 +0200
Re: acquire + sleep + async fir <profesor.fir@gmail.com> - 2026-06-10 16:03 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 04:40 +0000
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 07:20 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 06:28 +0000
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 09:21 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 07:45 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 15:56 -0700
Re: acquire + sleep + async David Brown <david.brown@hesbynett.no> - 2026-06-11 09:52 +0200
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 10:28 +0200
Re: acquire + sleep + async fir <profesor.fir@gmail.com> - 2026-06-11 10:44 +0200
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 11:36 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 01:32 +0000
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-12 06:16 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:19 -0700
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-12 13:15 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 12:15 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 23:52 +0000
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-13 05:05 +0200
Re: acquire + sleep + async scott@slp53.sl.home (Scott Lurndal) - 2026-06-13 14:52 +0000
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:12 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 12:22 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 03:09 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 20:29 -0700
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 20:30 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 04:11 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 00:18 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:23 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 11:47 -0700
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-18 18:23 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 12:46 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:01 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 13:34 -0700
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-20 11:47 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 22:41 +0000
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 23:29 +0000
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-21 09:06 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-21 07:50 +0000
Re: acquire + sleep + async David Brown <david.brown@hesbynett.no> - 2026-06-21 12:22 +0200
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-21 13:41 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 16:01 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 01:33 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:05 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 23:54 +0000
Re: acquire + sleep + async David Brown <david.brown@hesbynett.no> - 2026-06-11 13:39 +0200
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 16:44 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:11 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:01 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 13:46 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:32 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 12:23 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 03:07 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 12:47 -0700
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 12:51 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:14 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:16 -0700
Re: acquire + sleep + async fir <profesor.fir@gmail.com> - 2026-06-11 10:34 +0200
Re: acquire + sleep + async Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 11:38 +0200
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:13 +0000
Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:50 +0200
Re: Co-routines (was Re: acquire + sleep + async) David Brown <david.brown@hesbynett.no> - 2026-06-12 12:42 +0200
Re: Co-routines (was Re: acquire + sleep + async) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-12 13:18 +0200
Re: Co-routines (was Re: acquire + sleep + async) David Brown <david.brown@hesbynett.no> - 2026-06-12 13:59 +0200
Re: Co-routines (was Re: acquire + sleep + async) Michael S <already5chosen@yahoo.com> - 2026-06-12 18:42 +0300
Re: Co-routines (was Re: acquire + sleep + async) David Brown <david.brown@hesbynett.no> - 2026-06-12 18:20 +0200
Re: Co-routines (was Re: acquire + sleep + async) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-12 18:58 +0200
Re: Continuations (was Re: Coroutines) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:04 +0000
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-12 14:51 +0100
Re: Co-routines (was Re: acquire + sleep + async) David Brown <david.brown@hesbynett.no> - 2026-06-12 16:04 +0200
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-12 16:16 +0100
Re: Co-routines (was Re: acquire + sleep + async) David Brown <david.brown@hesbynett.no> - 2026-06-12 17:31 +0200
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 13:48 -0700
Re: Co-routines (was Re: acquire + sleep + async) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:13 -0700
Re: Co-routines (was Re: acquire + sleep + async) fir <profesor.fir@gmail.com> - 2026-06-12 16:25 +0200
Re: Co-routines (was Re: acquire + sleep + async) fir <profesor.fir@gmail.com> - 2026-06-12 16:28 +0200
Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 19:13 +0200
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 13:45 -0700
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 01:03 +0100
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 17:50 -0700
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 11:03 +0100
Re: Co-routines (was Re: acquire + sleep + async) tTh <tth@none.invalid> - 2026-06-13 12:14 +0200
Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:35 +0200
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-13 14:38 +0100
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 16:46 -0700
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-14 01:25 +0100
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 18:26 -0700
Re: Co-routines (was Re: acquire + sleep + async) Bart <bc@freeuk.com> - 2026-06-14 12:28 +0100
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:01 -0700
Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-22 19:46 +0200
Re: Co-routines (was Re: acquire + sleep + async) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 21:24 +0000
Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-23 01:16 +0200
Re: Co-routines (was Re: acquire + sleep + async) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:45 -0700
Re: Co-routines (was Re: acquire + sleep + async) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-13 03:48 -0700
Re: Co-routines (was Re: acquire + sleep + async) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 18:22 -0700
Re: Co-routines (was Re: acquire + sleep + async) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 18:14 +0200
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 14:18 -0700
Re: acquire + sleep + async Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:12 +0000
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:06 -0700
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 12:25 -0700
Re: acquire + sleep + async "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 12:11 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-06-13 12:14 +0200 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110jahn$1br9$1@news.gegeweb.eu> |
| In reply to | #400019 |
On 6/13/26 12:03, Bart wrote:
> Seriously? You have a language where you can literally do this:
>
> #include <stdint.h>
> int32_t int32_t;
> int32_t = 0;
>
> and that is just fine; just "don't do it"! In that case, we might as
> well allow:
>
> int int;
>
> Can you understand how crazy the above looks from outside?
In our technical jargon, we have the perfect acronym to
describe this kind of programming: GIGO. Look at wikipedia
for an astounding description of that syndrom.
https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-13 14:35 +0200 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110jir6$2097u$4@dont-email.me> |
| In reply to | #400020 |
On 2026-06-13 12:14, tTh wrote: > On 6/13/26 12:03, Bart wrote: > >> Seriously? You have a language where you can literally do this: >> >> #include <stdint.h> >> int32_t int32_t; >> int32_t = 0; >> >> and that is just fine; just "don't do it"! In that case, we might as >> well allow: >> >> int int; >> >> Can you understand how crazy the above looks from outside? Yes. (And I suppose everyone here understands that!) Languages have various possibilities to define their lexical rules, their syntax, and their semantics. It's certainly quite common to have _reserved words_ that may only be used in certain syntactical contexts. But there's also languages that allow context-depending placement of names that happen to be also tokens of the language. Consider, for example, in shell: for for in in do ; do : ; done Such pieces of code are a result of a programmer's sick brain and not the problem of a language. Keith already noted: "Doctor, it hurts when I do this." And tTh said: > In our technical jargon, we have the perfect acronym to > describe this kind of programming: GIGO. Look at wikipedia > for an astounding description of that syndrom. > > https://en.wikipedia.org/wiki/Garbage_in,_garbage_out Bart, do you understand these hints? When will you recognize that "the problem" is your personal thing? (That's all just rhetorical; we know the answer: "Never!") Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-13 14:38 +0100 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110jmfs$2uovt$1@dont-email.me> |
| In reply to | #400027 |
On 13/06/2026 13:35, Janis Papanagnou wrote:
> On 2026-06-13 12:14, tTh wrote:
>> On 6/13/26 12:03, Bart wrote:
>>
>>> Seriously? You have a language where you can literally do this:
>>>
>>> #include <stdint.h>
>>> int32_t int32_t;
>>> int32_t = 0;
>>>
>>> and that is just fine; just "don't do it"! In that case, we might as
>>> well allow:
>>>
>>> int int;
>>>
>>> Can you understand how crazy the above looks from outside?
>
> Yes. (And I suppose everyone here understands that!)
Thank you for at least acknowledging that.
> Languages have various possibilities to define their lexical rules,
> their syntax, and their semantics.
>
> It's certainly quite common to have _reserved words_ that may only
> be used in certain syntactical contexts. But there's also languages
> that allow context-depending placement of names that happen to be
> also tokens of the language.
>
> Consider, for example, in shell: for for in in do ; do : ; done
In the case of 'int32_t' this is supposedly a core C type but it is
quite unknown to the language until you include a particular header.
But my example highlighted the fact that you can do this:
Point Point;
provided the first Point is a user-defined type defined in an outer
scope. Further:
Point typedef Point; // new scope starts at that 'typedef'
{Point Point;}
> Such pieces of code are a result of a programmer's sick brain and
> not the problem of a language.
Such pieces of code are 100% *enabled* by the language so, yes, you can
blame the language. These examples are not possible in mine for example,
due to different scoping rules.
So someone using my product /has/ to write:
type newPoint = Point
'type' has to be on the left, and the alias has to have a different name.
Quite draconian, I know! A programmer can still do 'crazy' stuff, but
they have to work harder.
The attitude here seems to be, if you can write nonsense in any language
anyway, then why bother making it harder to do so? Let's have fewer
rules and make it easier!
> Keith already noted: "Doctor, it hurts when I do this."
>
> And tTh said:
>
>> In our technical jargon, we have the perfect acronym to
>> describe this kind of programming: GIGO. Look at wikipedia
>> for an astounding description of that syndrom.
>>
>> https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
>
> Bart, do you understand these hints? When will you recognize that
> "the problem" is your personal thing? (That's all just rhetorical;
> we know the answer: "Never!")
What problem are we talking about?
I'd merely commented that some of the 'huge improvements' made to C were
done very crudely. And actually it was Keith who brought up stdint.h types.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-13 16:46 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110kq43$399nk$1@kst.eternal-september.org> |
| In reply to | #400031 |
Bart <bc@freeuk.com> writes:
> On 13/06/2026 13:35, Janis Papanagnou wrote:
>> On 2026-06-13 12:14, tTh wrote:
>>> On 6/13/26 12:03, Bart wrote:
>>>> Seriously? You have a language where you can literally do this:
>>>>
>>>> #include <stdint.h>
>>>> int32_t int32_t;
>>>> int32_t = 0;
>>>>
>>>> and that is just fine; just "don't do it"! In that case, we might
>>>> as well allow:
>>>>
>>>> int int;
>>>>
>>>> Can you understand how crazy the above looks from outside?
>> Yes. (And I suppose everyone here understands that!)
>
> Thank you for at least acknowledging that.
You seem think that acknowledgement is important. Upthread, you
asked a question. I spent substantial time and effort answering
it. You have not acknowledged that. I don't think you've ever
acnowledged it when I've answered one of your questions. Why is
that?
(I don't expect acknowledgement from you. I enjoyed writing the
explanation, and I hope that others might benefit from it, or at
least find it interesting.)
[...]
> In the case of 'int32_t' this is supposedly a core C type but it is
> quite unknown to the language until you include a particular header.
Who said it was a "core C type"? What does "core C type" even mean?
(It's not mentioned in 6.2.3, "Types".)
Not all implementations necessarily even define int32_t.
Yes, it's defined in a header. Everyone knows that. And everyone
knows that you don't like it.
> But my example highlighted the fact that you can do this:
>
> Point Point;
>
> provided the first Point is a user-defined type defined in an outer
> scope. Further:
>
> Point typedef Point; // new scope starts at that 'typedef'
> {Point Point;}
Yet again, "Doctor, it hurts when I do this."
No language makes it impossible to write ugly code.
Perhaps C has some features that make it easier to write ugly code
in some cases. "Fixing" those features would make the language more
complicated and break existing code, including code that isn't ugly
at all.
[...]
> The attitude here seems to be, if you can write nonsense in any
> language anyway, then why bother making it harder to do so? Let's have
> fewer rules and make it easier!
No, that's what the attitude here seems *to you* to be. As usual,
you've misunderstood what everyone else here thinks.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-14 01:25 +0100 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110kse3$39nom$1@dont-email.me> |
| In reply to | #400043 |
On 14/06/2026 00:46, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 13/06/2026 13:35, Janis Papanagnou wrote:
>>> On 2026-06-13 12:14, tTh wrote:
>>>> On 6/13/26 12:03, Bart wrote:
>>>>> Seriously? You have a language where you can literally do this:
>>>>>
>>>>> #include <stdint.h>
>>>>> int32_t int32_t;
>>>>> int32_t = 0;
>>>>>
>>>>> and that is just fine; just "don't do it"! In that case, we might
>>>>> as well allow:
>>>>>
>>>>> int int;
>>>>>
>>>>> Can you understand how crazy the above looks from outside?
>>> Yes. (And I suppose everyone here understands that!)
>>
>> Thank you for at least acknowledging that.
>
> You seem think that acknowledgement is important. Upthread, you
> asked a question. I spent substantial time and effort answering
> it. You have not acknowledged that. I don't think you've ever
> acnowledged it when I've answered one of your questions. Why is
> that?
You seem touchy about this. Sometimes I write considerable amounts only
for people to complete ignore the content, or just snip it. It happens.
I can't remember anyone thanking me for anything.
Regarding your comments about why compound literals look like they do,
it sounded like speculation on your part. Not much for me to say about
it other than putting another POV on some parts.
It still came across as excuses for something that you clearly think is
a trivial matter. I consider cleaner, less cluttered code important.
> (I don't expect acknowledgement from you. I enjoyed writing the
> explanation, and I hope that others might benefit from it, or at
> least find it interesting.)
>
> [...]
>
>> In the case of 'int32_t' this is supposedly a core C type but it is
>> quite unknown to the language until you include a particular header.
>
> Who said it was a "core C type"? What does "core C type" even mean?
> (It's not mentioned in 6.2.3, "Types".)
It came up in a thread last year where it was suggested that stdint
types were pretty much of the same rank as 'char short int long' etc.
I'm not going to trawl through of posts to try and find it.
Of course I don't agree that they are a core type; they are usually
typedefs around 'char short' etc.
>> But my example highlighted the fact that you can do this:
>>
>> Point Point;
>>
>> provided the first Point is a user-defined type defined in an outer
>> scope. Further:
>>
>> Point typedef Point; // new scope starts at that 'typedef'
>> {Point Point;}
>
> Yet again, "Doctor, it hurts when I do this."
And yet again on my part, why allow it in the first place?
C uses declarations where the type comes first. Now it is more
fashionable for the type to come after the identifier being defined.
Then my example changes from:
Point [type] Point [var]; // [] annotations added
to:
Point [var] : Point [type];
In the first, the scope for 'Point [var] starts just before that and
shadows Point [type]. But in the second, it doesn't work: Point [var]
shadows the other, then has to swap back for one token to allow Point
[type] to be visible.
It suggests the concept is flawed if scope relies on a particular
ordering of type/var.
>> The attitude here seems to be, if you can write nonsense in any
>> language anyway, then why bother making it harder to do so? Let's have
>> fewer rules and make it easier!
>
> No, that's what the attitude here seems *to you* to be. As usual,
> you've misunderstood what everyone else here thinks.
Countless posts here that people have made suggested exactly that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-13 18:26 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110l00u$399nk$3@kst.eternal-september.org> |
| In reply to | #400044 |
Bart <bc@freeuk.com> writes:
> On 14/06/2026 00:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 13/06/2026 13:35, Janis Papanagnou wrote:
>>>> On 2026-06-13 12:14, tTh wrote:
>>>>> On 6/13/26 12:03, Bart wrote:
>>>>>> Seriously? You have a language where you can literally do this:
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> int32_t int32_t;
>>>>>> int32_t = 0;
>>>>>>
>>>>>> and that is just fine; just "don't do it"! In that case, we might
>>>>>> as well allow:
>>>>>>
>>>>>> int int;
>>>>>>
>>>>>> Can you understand how crazy the above looks from outside?
>>>> Yes. (And I suppose everyone here understands that!)
>>>
>>> Thank you for at least acknowledging that.
>> You seem think that acknowledgement is important. Upthread, you
>> asked a question. I spent substantial time and effort answering
>> it. You have not acknowledged that. I don't think you've ever
>> acnowledged it when I've answered one of your questions. Why is
>> that?
>
> You seem touchy about this. Sometimes I write considerable amounts
> only for people to complete ignore the content, or just snip it. It
> happens. I can't remember anyone thanking me for anything.
Not the same thing.
I said "acknowledged", not "thanked". And I wrote what I wrote in
direct response to a question that you asked.
Here's what you wrote:
"""
Regarding compound literals, why is one necessary when assigning to
'q' here:
typedef struct {double x, y;} Point;
Point p = {10, 20};
Point q;
q = (Point){30, 40};
"""
> Regarding your comments about why compound literals look like they do,
> it sounded like speculation on your part. Not much for me to say about
> it other than putting another POV on some parts.
I'd say my answer was *informed* speculation, based on the facts
about how compound literals are defined and my knowledge of the
implications of other possible definitions (in particular, that
a version without the type name probably couldn't be made to work
without radical and otherwise unnecessary changes to C). If you
really want to know what the authors of the standard had in mind,
you can search through the committee's published documents as well
as I can. I don't believe that's what you want to know.
Tell me this. Were you really interested in an actual answer to your
question, or was it just a rhetorical method to complain yet again
about a feature of C that you don't like? I foolishly assumed that
you wanted an answer. All the evidence suggests that you didn't.
Should I assume that any time you ask a question about C, particularly
about why a feature you dislike is the way it is, that you really don't
care about the answer?
> It still came across as excuses for something that you clearly think
> is a trivial matter. I consider cleaner, less cluttered code
> important.
Explanations, not excuses, for a decision for which there were valid
reasons that you refuse to acknowledge or accept.
>> (I don't expect acknowledgement from you. I enjoyed writing the
>> explanation, and I hope that others might benefit from it, or at
>> least find it interesting.)
>> [...]
>>
>>> In the case of 'int32_t' this is supposedly a core C type but it is
>>> quite unknown to the language until you include a particular header.
>> Who said it was a "core C type"? What does "core C type" even mean?
>> (It's not mentioned in 6.2.3, "Types".)
>
> It came up in a thread last year where it was suggested that stdint
> types were pretty much of the same rank as 'char short int long'
> etc. I'm not going to trawl through of posts to try and find it.
The word "rank" has a specific meaning; I presume that's not what
you meant. If that other person did mean "rank" in that sense,
then it was likely to be a correct statement; if int32_t is a
typedef for int, then it has the same rank as int.
And I suppose I have to admit that my question was rhetorical.
Touché.
int32_t is not a "core C type", for any reasonable definition of that
vague phrase. If someone said it is, I disagree, but I also am not
going to trawl through posts to find it.
> Of course I don't agree that they are a core type; they are usually
> typedefs around 'char short' etc.
>
>>> But my example highlighted the fact that you can do this:
>>>
>>> Point Point;
>>>
>>> provided the first Point is a user-defined type defined in an outer
>>> scope. Further:
>>>
>>> Point typedef Point; // new scope starts at that 'typedef'
>>> {Point Point;}
>> Yet again, "Doctor, it hurts when I do this."
>
> And yet again on my part, why allow it in the first place?
I could answer that, but I'm nearly certain you would not be
interested in the answer.
> C uses declarations where the type comes first. Now it is more
> fashionable for the type to come after the identifier being
> defined.
It is not "fashionable" in any sense relevant to the topic of this
newsgroup. Yes, different languages have different declaration
syntax. I'll even acknowledge that the declaration syntax of some
other languages has real advantages over C's. But C is what we
try to discuss here.
[...]
>>> The attitude here seems to be, if you can write nonsense in any
>>> language anyway, then why bother making it harder to do so? Let's have
>>> fewer rules and make it easier!
>>
>> No, that's what the attitude here seems *to you* to be. As usual,
>> you've misunderstood what everyone else here thinks.
>
> Countless posts here that people have made suggested exactly that.
You're wrong. I won't bother to explain why. I might if you could
convince me that the explanation would be of any interest to you,
but that seems unlikely.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-14 12:28 +0100 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110m383$3j7d6$1@dont-email.me> |
| In reply to | #400047 |
On 14/06/2026 02:26, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> Regarding your comments about why compound literals look like they do,
>> it sounded like speculation on your part. Not much for me to say about
>> it other than putting another POV on some parts.
>
> I'd say my answer was *informed* speculation, based on the facts
> about how compound literals are defined and my knowledge of the
> implications of other possible definitions (in particular, that
> a version without the type name probably couldn't be made to work
> without radical and otherwise unnecessary changes to C). If you
> really want to know what the authors of the standard had in mind,
> you can search through the committee's published documents as well
> as I can. I don't believe that's what you want to know.
>
> Tell me this. Were you really interested in an actual answer to your
> question, or was it just a rhetorical method to complain yet again
> about a feature of C that you don't like?
Why is this such a big deal?
I find it annoying that one has to write 'a = (T){b}' instead of just 'a
= {b}' (**)
I asked 'why' that was necessary. You gave a complicated response which
boils down to it being too hard to do or not practical. Or maybe nobody
cared enough about readability to try a bit harder.
I then questioned some of the responses as I think it /would/ have been
possible.
Since I know the decision has been made, this is not going to change C.
But it is interesting to me from a PL design POV.
I acknowledged it my making a reply; I could have decided to leave it there.
(** I have to write 'a := T(b)' in my scripting language, when T is
record type, for example 'a := point(10, 20)'.
But there is a good reason: 'a' has a dynamic type so that info has to
be provided as it cannot be infered from the type of 'a'.
But C is a statically typed language: it should not be necessary. You
yourself gave examples where it wasn't, and I gave an example from mine
for what is /basically the same language/, in type system and capabilities.)
I foolishly assumed that
> you wanted an answer. All the evidence suggests that you didn't.
>
> Should I assume that any time you ask a question about C, particularly
> about why a feature you dislike is the way it is, that you really don't
> care about the answer?
>
>> It still came across as excuses for something that you clearly think
>> is a trivial matter. I consider cleaner, less cluttered code
>> important.
>
> Explanations, not excuses, for a decision for which there were valid
> reasons that you refuse to acknowledge or accept.
>
>>> (I don't expect acknowledgement from you. I enjoyed writing the
>>> explanation, and I hope that others might benefit from it, or at
>>> least find it interesting.)
>>> [...]
>>>
>>>> In the case of 'int32_t' this is supposedly a core C type but it is
>>>> quite unknown to the language until you include a particular header.
>>> Who said it was a "core C type"? What does "core C type" even mean?
>>> (It's not mentioned in 6.2.3, "Types".)
>>
>> It came up in a thread last year where it was suggested that stdint
>> types were pretty much of the same rank as 'char short int long'
>> etc. I'm not going to trawl through of posts to try and find it.
>
> The word "rank" has a specific meaning; I presume that's not what
> you meant. If that other person did mean "rank" in that sense,
> then it was likely to be a correct statement; if int32_t is a
> typedef for int, then it has the same rank as int.
>
> And I suppose I have to admit that my question was rhetorical.
> Touché.
>
> int32_t is not a "core C type", for any reasonable definition of that
> vague phrase. If someone said it is, I disagree, but I also am not
> going to trawl through posts to find it.
>
>> Of course I don't agree that they are a core type; they are usually
>> typedefs around 'char short' etc.
>>
>>>> But my example highlighted the fact that you can do this:
>>>>
>>>> Point Point;
>>>>
>>>> provided the first Point is a user-defined type defined in an outer
>>>> scope. Further:
>>>>
>>>> Point typedef Point; // new scope starts at that 'typedef'
>>>> {Point Point;}
>>> Yet again, "Doctor, it hurts when I do this."
>>
>> And yet again on my part, why allow it in the first place?
>
> I could answer that, but I'm nearly certain you would not be
> interested in the answer.
>
>> C uses declarations where the type comes first. Now it is more
>> fashionable for the type to come after the identifier being
>> defined.
>
> It is not "fashionable" in any sense relevant to the topic of this
> newsgroup. Yes, different languages have different declaration
> syntax. I'll even acknowledge that the declaration syntax of some
> other languages has real advantages over C's. But C is what we
> try to discuss here.
>
> [...]
>
>>>> The attitude here seems to be, if you can write nonsense in any
>>>> language anyway, then why bother making it harder to do so? Let's have
>>>> fewer rules and make it easier!
>>>
>>> No, that's what the attitude here seems *to you* to be. As usual,
>>> you've misunderstood what everyone else here thinks.
>>
>> Countless posts here that people have made suggested exactly that.
>
> You're wrong. I won't bother to explain why. I might if you could
> convince me that the explanation would be of any interest to you,
> but that seems unlikely.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-14 15:01 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110n8c2$3u4l5$1@kst.eternal-september.org> |
| In reply to | #400048 |
Bart <bc@freeuk.com> writes:
> On 14/06/2026 02:26, Keith Thompson wrote:
[...]
>> Tell me this. Were you really interested in an actual answer to your
>> question, or was it just a rhetorical method to complain yet again
>> about a feature of C that you don't like?
>
> Why is this such a big deal?
I might consider answering that if I thought you were actually
interested in an answer.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-22 19:46 +0200 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <111bsd2$305a4$1@dont-email.me> |
| In reply to | #400031 |
On 2026-06-13 15:38, Bart wrote:
> On 13/06/2026 13:35, Janis Papanagnou wrote:
>> On 2026-06-13 12:14, tTh wrote:
>>> On 6/13/26 12:03, Bart wrote:
>>>
>>>> Seriously? You have a language where you can literally do this:
>>>>
>>>> #include <stdint.h>
>>>> int32_t int32_t;
>>>> int32_t = 0;
>>>>
>>>> and that is just fine; just "don't do it"! In that case, we might as
>>>> well allow:
>>>>
>>>> int int;
>>>>
>>>> Can you understand how crazy the above looks from outside?
>>
>> Yes. (And I suppose everyone here understands that!)
>
> Thank you for at least acknowledging that.
Huh? - There's nothing to acknowledge here since it's obvious.
All I intended to say with that was that you are constructing
strange reasoning based on trivialities. - This is actually a
well known and often applied rhetoric move; hunt for agreement
by stating a triviality to get assurance for all the debatable
stuff.
>
>> Languages have various possibilities to define their lexical rules,
>> their syntax, and their semantics.
>>
>> It's certainly quite common to have _reserved words_ that may only
>> be used in certain syntactical contexts. But there's also languages
>> that allow context-depending placement of names that happen to be
>> also tokens of the language.
>>
>> Consider, for example, in shell: for for in in do ; do : ; done
> In the case of 'int32_t' this is supposedly a core C type but it is
> quite unknown to the language until you include a particular header.
Yes. That's something that I (also?) don't think is good language
design. (Many things in "C" I actually consider to be kludges and
quirks; but so what?)
For what reason do you want to discuss all the design decisions of
the C-language? (I'm certainly not the appropriate partner for you
since, depending on the project, I either use "C" - as it is! - or
use another (for the respective task) more appropriate language.)
But, specifically, and for whatever product I develop, I wouldn't
use any proprietary, non-standard, home-brewed product. - So your
(repeated!) advertisement of your toys is meaningless.
> [...]
>> Such pieces of code are a result of a programmer's sick brain and
>> not the problem of a language.
>
> Such pieces of code are 100% *enabled* by the language so, yes, you can
> blame the language.
(My statement was on the shell-code. Your examples about "C". Just
noting.)
Since you might not have noticed; I don't write such shell-code.
And I also don't complain (in this respect) about shell's design.
It was about that there's different design options on that level.
What I said was that in either language you have to make decisions.
The shell-designers obviously didn't want to restrict use of values
and names, therefore they consider context.[*] In other languages
they may have different name spaces (cf. Algol 68 "stropping"), or
they use _reserved words_ (as already mentioned). The problem with
the former is that some people (like you) might not like "stropping".
Other folks might not like being restricted in their choice of names
to non-reserved words only. Languages like "C" have reduced these
reserved keywords; at the cost of other syntactic arguable choices,
choices that I personally don't like.
There's obviously no clear "design principle X is good" and "design
principle Y is bad" that fits everyone. (And I'm sure only your own
personal language designs are the only ones that fits your liking.
I'm fine with that.)
I, for example, would like to use common abbreviation for locally
scoped entities, like 'Interface if;' or 'int if = 0;' - but
I cannot do that; I have to follow to the rules that the language
designers have set. (And the 'if' example is not restricted to the
C-language, it's quite common to be a reserved word in languages!)
You cannot fundamentally change "C" as it is; not after more than
five decades (since its birth), and also not after it had been
standardized; it just makes no sense to even start an argument on
that. - If you think it's "bad" don't use it.
> These examples are not possible in mine for example,
> due to different scoping rules.
That's fine. If you find someone who is interested in your language
he might appreciate it (or not; can't tell, and I don't care).
> [...]
>
> Quite draconian, I know! A programmer can still do 'crazy' stuff, but
> they have to work harder.
The point that had been tried to convey was that it's *not* in the
first place a language issue; it's an issue the programmer invented.
Consider, example for, text this. From composed punctuation it
language rules is the of words English and. Just not artifacts
possible defined say would such English it to positive language
badly the is create I that is because am you. Would the, text
and rightly, of writer blame you so that.
Oh, wait! I'll translate that for you:
Consider, for example, this text. It is composed of words and
punctuation rules from the English language. I am positive you
would not say that the English language is badly defined just
because it is possible to create such artifacts. You would,
and rightly so, blame the writer of that text.
I'm with you (of course) that a language should be safe, and clearly
defined. But your examples and personal problems [with "C"] are not
rooted in the language (that it allows writing stupid things) but in
the person who writes such code, either in practice or (as you) just
for purpose of an argument.
>
> The attitude here seems to be, if you can write nonsense in any language
> anyway, then why bother making it harder to do so? Let's have fewer
> rules and make it easier!
Can't tell (and don't want to speak) about attitudes. What repeatedly
had been said here was that you cannot change the "C" language just
as you (or anyone else) would like. - "C" is not important enough for
me to engage here. But if you feel there's something essential that
should (and could, without breaking anything) be changed, I'd suggest
to contact the standards group and submit a proposal.
Janis
[*] But note that they also used 'do'...'done' instead of 'do'...'od'
because of existence of the Unix 'od' command.
> [...]
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-22 21:24 +0000 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <3Kh_R.14$tqq4.9@fx39.iad> |
| In reply to | #400194 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-06-13 15:38, Bart wrote: >> On 13/06/2026 13:35, Janis Papanagnou wrote: >>> On 2026-06-13 12:14, tTh wrote: >>>> On 6/13/26 12:03, Bart wrote: >>>> >>>>> Seriously? You have a language where you can literally do this: >>>>> >>>>> #include <stdint.h> >>>>> int32_t int32_t; >>>>> int32_t = 0; >>>>> >>>>> and that is just fine; just "don't do it"! In that case, we might as >>>>> well allow: >>>>> >>>>> int int; >>>>> >>>>> Can you understand how crazy the above looks from outside? <pins> >> In the case of 'int32_t' this is supposedly a core C type but it is >> quite unknown to the language until you include a particular header. > >Yes. That's something that I (also?) don't think is good language >design. (Many things in "C" I actually consider to be kludges and >quirks; but so what?) Technically, the C language evolved, it wasn't designed per se. And there are good reasons (backward compatability) for conditioning support of the fixed size types on inclusion of <stdint.h> rather than building them into the language. Like it or not, it cannot be changed.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-23 01:16 +0200 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <111cfnu$305a4$2@dont-email.me> |
| In reply to | #400200 |
On 2026-06-22 23:24, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-06-13 15:38, Bart wrote: >>> [...] >>> In the case of 'int32_t' this is supposedly a core C type but it is >>> quite unknown to the language until you include a particular header. >> >> Yes. That's something that I (also?) don't think is good language >> design. (Many things in "C" I actually consider to be kludges and >> quirks; but so what?) > > Technically, the C language evolved, it wasn't designed per se. Well, yes and no. For me the _original design_ is responsible also for a lot that was (had to be) adjusted, fixed, and extended later. > > And there are good reasons (backward compatability) for conditioning > support of the fixed size types on inclusion of <stdint.h> rather than > building them into the language. Sure. > Like it or not, it cannot be changed. That's what I'm also regularly saying. - In my longish post you may have missed it: You cannot fundamentally change "C" as it is; not after more than five decades (since its birth), and also not after it had been standardized; it just makes no sense to even start an argument on that. - If you think it's "bad" don't use it. Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 12:45 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <86a4qo7afi.fsf@linuxsc.com> |
| In reply to | #400200 |
scott@slp53.sl.home (Scott Lurndal) writes: [.. whether types like int32_t should be part of the base language ..] > And there are good reasons (backward compatability) for conditioning > support of the fixed size types on inclusion of <stdint.h> rather > than building them into the language. Like it or not, it cannot be > changed. It isn't necessary to use <stdint.h> to give names to fixed-width integer types. A lot of people do it but it isn't necessary.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-13 03:48 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110jchl$2s7bc$1@kst.eternal-september.org> |
| In reply to | #400019 |
Bart <bc@freeuk.com> writes:
[...]
> My language is much closer to C, and it doesn't have much problem with
> it. I was merely asking why you have to write:
>
> DrawLine((Point){x1, y1}, (Point){x2, y2});
>
> rather than:
>
> DrawLine({x1, y1}, {x2, y2});
You asked. I answered.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-21 18:22 -0700 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <864iiv8j34.fsf@linuxsc.com> |
| In reply to | #399985 |
Bart <bc@freeuk.com> writes:
> Regarding compound literals, why is one necessary when assigning to
> q' here:
>
> typedef struct {double x, y;} Point;
>
> Point p = {10, 20};
> Point q;
> q = (Point){30, 40};
>
> The initialisation of 'p' doesn't need it, so can't you just do this:
>
> q = {30, 40};
This idea might be workable in some situations. Certainly though
there are lots of other situations where it is not workable. The
matter can be seen as a language design question: is it better to
have a simpler language that is somewhat less convenient, or is it
better to have a more complicated language that is somewhat more
convenient? Surely most people would _not_ say that C expression
syntax is too simple, and so should be more elaborate. What is the
convenience of the proposed addition worth? Does the cost in added
language complexity justify the benefit in programming convenience?
Would other readers like to weigh in on these question?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-12 18:14 +0200 |
| Subject | Re: Co-routines (was Re: acquire + sleep + async) |
| Message-ID | <110hb8j$2097u$2@dont-email.me> |
| In reply to | #399964 |
On 2026-06-12 12:42, David Brown wrote: > [ coroutines; C++, C, Go, Python ] Thanks for the descriptions. - It's probably worth (and useful to better understand the various designs) to have some sample code. You certainly made me curious, and on occasion I'll inspect those languages in more detail concerning their designs of co-routines. > [ about substantial progress in C-language evolution ] Well, I don't think this addressed the "personal abstraction" view I mentioned to explain subjectively differing valuations, but since my intention was anyway to not foster that subjective sub-topic, I leave it here as it is. ;-) > I had not intended to reply to Bonita here - replying to Bonita is > seldom useful IME, especially in c.l.c. But I am happy to reply to your > posts! Thanks for that appreciation. :-) Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-11 14:18 -0700 |
| Message-ID | <110f8mk$1ohhg$1@dont-email.me> |
| In reply to | #399880 |
On 6/10/2026 9:40 PM, Lawrence D’Oliveiro wrote: > On Wed, 10 Jun 2026 13:53:59 +0200, fir wrote: > >> im not experienced with multithreading programing ... > > It does tend to be error-prone. > > That’s why it is best reserved for CPU-intensive tasks that can > benefit from running a bunch of cores at once. > > For cases where the bottleneck is in the I/O or the network connection > (which is a lot of them), threading is typically unnecessary. Instead, > the popular approach nowadays is to use coroutines. Not sure why you say that. Threads work perfectly fine with I/O, network connections, ect... Do you think sync between processes is easier? > > <https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS/Introducing> > <https://docs.python.org/3/library/asyncio.html>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-12 00:12 +0000 |
| Message-ID | <110fitv$1r13s$2@dont-email.me> |
| In reply to | #399916 |
On Thu, 11 Jun 2026 14:18:09 -0700, Chris M. Thomasson wrote: > On 6/10/2026 9:40 PM, Lawrence D’Oliveiro wrote: >> >> For cases where the bottleneck is in the I/O or the network >> connection (which is a lot of them), threading is typically >> unnecessary. Instead, the popular approach nowadays is to use >> coroutines. > > Not sure why you say that. >> >> It does tend to be error-prone. >> >> That’s why it is best reserved for CPU-intensive tasks that can >> benefit from running a bunch of cores at once.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-11 21:06 -0700 |
| Message-ID | <110g0jg$1u4e2$2@dont-email.me> |
| In reply to | #399927 |
On 6/11/2026 5:12 PM, Lawrence D’Oliveiro wrote: > On Thu, 11 Jun 2026 14:18:09 -0700, Chris M. Thomasson wrote: > >> On 6/10/2026 9:40 PM, Lawrence D’Oliveiro wrote: >>> >>> For cases where the bottleneck is in the I/O or the network >>> connection (which is a lot of them), threading is typically >>> unnecessary. Instead, the popular approach nowadays is to use >>> coroutines. >> >> Not sure why you say that. >>> >>> It does tend to be error-prone. Well, shit happens. :^) >>> >>> That’s why it is best reserved for CPU-intensive tasks that can >>> benefit from running a bunch of cores at once.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-16 12:25 -0700 |
| Message-ID | <110s7up$1bro7$4@dont-email.me> |
| In reply to | #399947 |
On 6/11/2026 9:06 PM, Chris M. Thomasson wrote: > On 6/11/2026 5:12 PM, Lawrence D’Oliveiro wrote: >> On Thu, 11 Jun 2026 14:18:09 -0700, Chris M. Thomasson wrote: >> >>> On 6/10/2026 9:40 PM, Lawrence D’Oliveiro wrote: >>>> >>>> For cases where the bottleneck is in the I/O or the network >>>> connection (which is a lot of them), threading is typically >>>> unnecessary. Instead, the popular approach nowadays is to use >>>> coroutines. >>> >>> Not sure why you say that. >>>> >>>> It does tend to be error-prone. > > Well, shit happens. :^) Error prone... Well, C is not the lang that takes the corks off the forks: (Dirty Rotten Scoundrels (1988) - Dinner With Ruprecht Scene (6/12) | Movieclips) https://youtu.be/SKDX-qJaJ08 rofl! > > >>>> >>>> That’s why it is best reserved for CPU-intensive tasks that can >>>> benefit from running a bunch of cores at once. > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-17 12:11 -0700 |
| Message-ID | <110urh3$23911$2@dont-email.me> |
| In reply to | #400084 |
On 6/16/2026 12:25 PM, Chris M. Thomasson wrote: > On 6/11/2026 9:06 PM, Chris M. Thomasson wrote: >> On 6/11/2026 5:12 PM, Lawrence D’Oliveiro wrote: >>> On Thu, 11 Jun 2026 14:18:09 -0700, Chris M. Thomasson wrote: >>> >>>> On 6/10/2026 9:40 PM, Lawrence D’Oliveiro wrote: >>>>> >>>>> For cases where the bottleneck is in the I/O or the network >>>>> connection (which is a lot of them), threading is typically >>>>> unnecessary. Instead, the popular approach nowadays is to use >>>>> coroutines. >>>> >>>> Not sure why you say that. >>>>> >>>>> It does tend to be error-prone. >> >> Well, shit happens. :^) > > Error prone... Well, C is not the lang that takes the corks off the forks: Damn typos. C will let Ruprecht stab himself in the eyes. ;^) > > > (Dirty Rotten Scoundrels (1988) - Dinner With Ruprecht Scene (6/12) | > Movieclips) > > https://youtu.be/SKDX-qJaJ08 > > rofl! > > >> >> >>>>> >>>>> That’s why it is best reserved for CPU-intensive tasks that can >>>>> benefit from running a bunch of cores at once. >> >> >
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web