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

Groups > comp.lang.c++ > #81356 > unrolled thread

"C++20 Coroutines" by Martin Bond

Back to article view | Back to comp.lang.c++

Contents

  "C++20 Coroutines" by Martin Bond Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-20 16:30 -0500
    Re: "C++20 Coroutines" by Martin Bond Bo Persson <bo@bo-persson.se> - 2021-09-21 09:28 +0200
    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-21 11:45 +0200
      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-21 15:37 +0000
        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-21 17:40 +0200
        Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-22 05:22 +0000
          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-22 09:26 +0000
            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-22 16:40 +0200
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-22 15:01 +0000
                Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-23 05:38 +0200
                  Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-23 09:05 +0000
                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:15 +0200
                      Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:57 +0000
                  Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-23 09:11 +0000
                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:17 +0200
                      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:19 +0000
                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:00 +0200
                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:09 +0000
                            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:18 +0200
                              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:39 +0000
                                Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 12:42 +0200
                                  Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 10:44 +0000
                                    Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 13:14 +0200
                                      Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:44 +0000
                                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 15:58 +0200
                                          Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 13:59 +0000
                                            Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 16:23 +0200
                                              Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 07:24 +0200
                                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 15:28 +0000
                                      Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 15:04 +0000
                                        Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 18:44 +0200
                                          Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-26 14:15 +0000
                        Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:32 +0000
            Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:42 +0000
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-23 09:14 +0000
                Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-24 04:42 +0000
              Re: "C++20 Coroutines" by Martin Bond Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:19 +0200
                Re: "C++20 Coroutines" by Martin Bond Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-24 21:07 +0100
                  Re: "C++20 Coroutines" by Martin Bond Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:19 -0700
                Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 00:58 +0000
                  Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:39 +0000
                    Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:30 +0000
                Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:20 +0000
          Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-22 11:31 +0200
        Re: "C++20 Coroutines" by Martin Bond Sam <sam@email-scan.com> - 2021-09-22 18:43 -0400
          Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-23 07:45 +0000
            Re: "C++20 Coroutines" by Martin Bond "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-23 01:53 -0700
            Re: "C++20 Coroutines" by Martin Bond Sam <sam@email-scan.com> - 2021-09-24 19:21 -0400
              Re: "C++20 Coroutines" by Martin Bond HorseyWorsey@the_stables.com - 2021-09-25 09:28 +0000
                Re: "C++20 Coroutines" by Martin Bond Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:38 +0000
              Re: "C++20 Coroutines" by Martin Bond Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:42 +0000
    Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-25 15:14 +0200
      Re: "C++20 Coroutines" by Martin Bond Manfred <noname@add.invalid> - 2021-09-25 23:07 +0200
        Re: "C++20 Coroutines" by Martin Bond "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-26 01:50 +0200
          Re: "C++20 Coroutines" by Martin Bond Manfred <noname@add.invalid> - 2021-09-26 19:12 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#81610

Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
> State machines are spagetty if not OO. Think about it.

Off-topic, but could you please stop top-posting? It's annoying.

Just edit the original post, leaving the relevant part you are
responding to, and write your response below. Like I'm doing here.

[toc] | [prev] | [next] | [standalone]

#81662

On 2021-09-27, Juha Nieminen <nospam@thanks.invalid> wrote:
> Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
>> State machines are spagetty if not OO. Think about it.
>
> Off-topic, but could you please stop top-posting? It's annoying.
>
> Just edit the original post, leaving the relevant part you are
> responding to, and write your response below. Like I'm doing here.
I haven't mentioned that. Sure I can post normally, no problem,
i just wanted to MAKE A POINT :P

-- 

7-77-777
Evil Sinner!

[toc] | [prev] | [next] | [standalone]

#81535

On Fri, 24 Sep 2021 18:19:16 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.09.2021 um 09:42 schrieb Juha Nieminen:
>
>> No, yielding precisely *avoids* spaghetti code, ...
>
>State-machines are _always_ spahgetti-code (while( !end )
>switch( state ) { ... }), even when you write them conventionally.
>But coroutines  are _much_ more readable and maintainable.

LMFAO!!!!!!

[toc] | [prev] | [next] | [standalone]

#81407

On 22 Sep 2021 07:22, Juha Nieminen wrote:
> Coroutines are compared to cooperative multitasking

This is fast becoming the adopted terminology, but really it should be

Continuations are compared to coroutines


- Alf

[toc] | [prev] | [next] | [standalone]

#81434

[Multipart message — attachments visible in raw view] — view raw

HorseyWorsey@the_stables.com writes:

> Coroutines should have stayed in the microsoft world, not added to the C++
> standard. They're a solution looking for a problem.

I was about to make this exact comment. You saved me the trouble of doing  
that.

Microsoft hijacked the standardization process in order to get co-routines  
into C++. std::threads' poor performance on MS-Windows has been documented,  
due to underlying OS design and/or limitations. This was MS's way of  
attempting to implement an alternative fake-multithreading that doesn't suck  
on their platform.

[toc] | [prev] | [next] | [standalone]

#81444

Sam <sam@email-scan.com> wrote:
> Microsoft hijacked the standardization process in order to get co-routines  
> into C++. std::threads' poor performance on MS-Windows has been documented,  
> due to underlying OS design and/or limitations. This was MS's way of  
> attempting to implement an alternative fake-multithreading that doesn't suck  
> on their platform.

You seem to have a strange misconception that coroutines are nothing
but simulating multithreading in a single-threaded program.

They are aren't.

[toc] | [prev] | [next] | [standalone]

#81447

On 9/23/2021 12:45 AM, Juha Nieminen wrote:
> Sam <sam@email-scan.com> wrote:
>> Microsoft hijacked the standardization process in order to get co-routines
>> into C++. std::threads' poor performance on MS-Windows has been documented,
>> due to underlying OS design and/or limitations. This was MS's way of
>> attempting to implement an alternative fake-multithreading that doesn't suck
>> on their platform.
> 
> You seem to have a strange misconception that coroutines are nothing
> but simulating multithreading in a single-threaded program.
> 
> They are aren't.
> 

Jeeze... This makes me think of the time I was using fibers in windows. 
Iirc, it was for sorting things. Also, iirc, it was broken down into, 
multiple fibers on a single thread. Multiple threads per process, then 
multiple processes. This was so long ago its making my head itch. Back 
on WinNT 4.0.

I had to use them in Linux as well. Iirc, setcontext comes to mind. ;^)

[toc] | [prev] | [next] | [standalone]

#81527

[Multipart message — attachments visible in raw view] — view raw

Juha Nieminen writes:

> Sam <sam@email-scan.com> wrote:
> > Microsoft hijacked the standardization process in order to get co-routines
> > into C++. std::threads' poor performance on MS-Windows has been documented,
> > due to underlying OS design and/or limitations. This was MS's way of
> > attempting to implement an alternative fake-multithreading that doesn't  
> suck
> > on their platform.
>
> You seem to have a strange misconception that coroutines are nothing
> but simulating multithreading in a single-threaded program.
>
> They are aren't.

And I never said they are. They are not a simulation of multithreading.  
They're a failed simulation of multithreading, on a platform with a rather  
bad native implementation of multiple execution threads.

[toc] | [prev] | [next] | [standalone]

#81537

On Fri, 24 Sep 2021 19:21:10 -0400
Sam <sam@email-scan.com> wrote:
>This is a MIME GnuPG-signed message.  If you see this text, it means that
>your E-mail or Usenet software does not support MIME signed messages.
>The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
>To open this message correctly you will need to install E-mail or Usenet
>software that supports modern Internet standards.
>
>--=_monster.email-scan.com-165744-1632525670-0001
>Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit
>
>Juha Nieminen writes:
>
>> Sam <sam@email-scan.com> wrote:
>> > Microsoft hijacked the standardization process in order to get co-routines
>> > into C++. std::threads' poor performance on MS-Windows has been documented,
>
>> > due to underlying OS design and/or limitations. This was MS's way of
>> > attempting to implement an alternative fake-multithreading that doesn't  
>> suck
>> > on their platform.
>>
>> You seem to have a strange misconception that coroutines are nothing
>> but simulating multithreading in a single-threaded program.
>>
>> They are aren't.
>
>And I never said they are. They are not a simulation of multithreading.  
>They're a failed simulation of multithreading, on a platform with a rather  
>bad native implementation of multiple execution threads.

And a diabolical implementation of process spawning.

[toc] | [prev] | [next] | [standalone]

#81553

On 2021-09-25, HorseyWorsey@the_stables.com <HorseyWorsey@the_stables.com> wrote:
>
> And a diabolical implementation of process spawning.

Well if done properly it's just preemptive shceduler
that can schedule on single or multiple cores/cpus
>


-- 
7-77-777
Evil Sinner!

[toc] | [prev] | [next] | [standalone]

#81611

Sam <sam@email-scan.com> wrote:
>> Sam <sam@email-scan.com> wrote:
>> > Microsoft hijacked the standardization process in order to get co-routines
>> > into C++. std::threads' poor performance on MS-Windows has been documented,
>> > due to underlying OS design and/or limitations. This was MS's way of
>> > attempting to implement an alternative fake-multithreading that doesn't  
>> suck
>> > on their platform.
>>
>> You seem to have a strange misconception that coroutines are nothing
>> but simulating multithreading in a single-threaded program.
>>
>> They are aren't.
> 
> And I never said they are. They are not a simulation of multithreading.  
> They're a failed simulation of multithreading, on a platform with a rather  
> bad native implementation of multiple execution threads.

My claim still stands. You did nothing to refute it. You seem to have this
strange misconception that coroutines are only about simulating
multithreading, and nothing else. Whether you think they are a good or
a bad feature is completely irrelevant to this.

[toc] | [prev] | [next] | [standalone]

#81555

On 20 Sep 2021 23:30, Lynn McGuire wrote:
> "C++20 Coroutines" by Martin Bond
>     https://blog.feabhas.com/2021/09/c20-coroutines/
> 
> "There seems to be a lot of confusion around the implementation of C++20 
> coroutines, which I think is due to the draft technical specification 
> for C++20 stating that coroutines are a work in progress so we can’t 
> expect full compiler and library support at this point in time.
> A lot of the problems probably arise from the lack of official 
> documentation about working with coroutines. We have been given C++ 
> syntax support for coroutines (the co_yield and co_return) but without 
> all of what I consider full library support. The standard library has 
> hooks and basic functionality for supporting coroutines, but we must 
> incorporate this into our own classes. I anticipate that there will be 
> full library support for generator style coroutines in C++23."

The main confusion about C++20 “coroutines” is that they're general 
coroutines.

They're not: they're simple continuations, the special case of 
/stackless/ coroutines (no dedicated stack for each coroutine).

While that's nice performance-wise it's very limited, and the Microsoft 
style support framework adopted in C++20 requires you to build a full 
fledged star ship in order to lift a little pebble; it's, well, moronic.

---

I once started coding up real coroutines in terms of standard C++ threads.

That could be very useful, in contrast to the mostly useless C++17 
continuations.

However, I stopped fiddling with it when the complexity of the 
implementation overwhelmed me. No doubt because of a lack of experience 
in safe multi-tasking. It would be really nice if SOMEONE could do this: 
real general coroutines, by leveraging real C++ threads.

---

That could open the world of safe multi-tasking to C++ programmers in 
general.

Another such enabler: an implementation of Ada-like rendezvous.

And, and, ... Occam-like channels, maybe. :)


- Alf

[toc] | [prev] | [next] | [standalone]

#81589

On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
> On 20 Sep 2021 23:30, Lynn McGuire wrote:
>> "C++20 Coroutines" by Martin Bond
>>     https://blog.feabhas.com/2021/09/c20-coroutines/
>>
>> "There seems to be a lot of confusion around the implementation of 
>> C++20 coroutines, which I think is due to the draft technical 
>> specification for C++20 stating that coroutines are a work in progress 
>> so we can’t expect full compiler and library support at this point in 
>> time.
>> A lot of the problems probably arise from the lack of official 
>> documentation about working with coroutines. We have been given C++ 
>> syntax support for coroutines (the co_yield and co_return) but without 
>> all of what I consider full library support. The standard library has 
>> hooks and basic functionality for supporting coroutines, but we must 
>> incorporate this into our own classes. I anticipate that there will be 
>> full library support for generator style coroutines in C++23."
> 
> The main confusion about C++20 “coroutines” is that they're general 
> coroutines.
> 
> They're not: they're simple continuations, the special case of 
> /stackless/ coroutines (no dedicated stack for each coroutine).
> 
> While that's nice performance-wise it's very limited, and the Microsoft 
> style support framework adopted in C++20 requires you to build a full 
> fledged star ship in order to lift a little pebble; it's, well, moronic.
> 
> ---
> 
> I once started coding up real coroutines in terms of standard C++ threads.
> 
> That could be very useful, in contrast to the mostly useless C++17 
> continuations.
> 
> However, I stopped fiddling with it when the complexity of the 
> implementation overwhelmed me. No doubt because of a lack of experience 
> in safe multi-tasking. It would be really nice if SOMEONE could do this: 
> real general coroutines, by leveraging real C++ threads.
> 
> ---
> 
> That could open the world of safe multi-tasking to C++ programmers in 
> general.

I'm no expert in coroutines, but AFAIU their main advantage is to enable 
multitasking without the overhead of multithreading.
In order to achieve this, language support is needed that was just not 
available prior to C++20 (and even with C++20 such support is limited, 
so that only the subset of continuations is actually available, as you say)

The point being, if you try to do that using threads kind of defeats the 
purpose, doesn't it?
(even if you build this with full synchronization inside, you'll still 
pay the price of performance and resource usage, which can be relevant 
for this kind of thing)

> 
> Another such enabler: an implementation of Ada-like rendezvous.
> 
> And, and, ... Occam-like channels, maybe. :)
> 
> 
> - Alf

[toc] | [prev] | [next] | [standalone]

#81591

On 25 Sep 2021 23:07, Manfred wrote:
> On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
>> On 20 Sep 2021 23:30, Lynn McGuire wrote:
>>> "C++20 Coroutines" by Martin Bond
>>>     https://blog.feabhas.com/2021/09/c20-coroutines/
>>>
>>> "There seems to be a lot of confusion around the implementation of 
>>> C++20 coroutines, which I think is due to the draft technical 
>>> specification for C++20 stating that coroutines are a work in 
>>> progress so we can’t expect full compiler and library support at this 
>>> point in time.
>>> A lot of the problems probably arise from the lack of official 
>>> documentation about working with coroutines. We have been given C++ 
>>> syntax support for coroutines (the co_yield and co_return) but 
>>> without all of what I consider full library support. The standard 
>>> library has hooks and basic functionality for supporting coroutines, 
>>> but we must incorporate this into our own classes. I anticipate that 
>>> there will be full library support for generator style coroutines in 
>>> C++23."
>>
>> The main confusion about C++20 “coroutines” is that they're general 
>> coroutines.
>>
>> They're not: they're simple continuations, the special case of 
>> /stackless/ coroutines (no dedicated stack for each coroutine).
>>
>> While that's nice performance-wise it's very limited, and the 
>> Microsoft style support framework adopted in C++20 requires you to 
>> build a full fledged star ship in order to lift a little pebble; it's, 
>> well, moronic.
>>
>> ---
>>
>> I once started coding up real coroutines in terms of standard C++ 
>> threads.
>>
>> That could be very useful, in contrast to the mostly useless C++17 
>> continuations.
>>
>> However, I stopped fiddling with it when the complexity of the 
>> implementation overwhelmed me. No doubt because of a lack of 
>> experience in safe multi-tasking. It would be really nice if SOMEONE 
>> could do this: real general coroutines, by leveraging real C++ threads.
>>
>> ---
>>
>> That could open the world of safe multi-tasking to C++ programmers in 
>> general.
> 
> I'm no expert in coroutines, but AFAIU their main advantage is to enable 
> multitasking without the overhead of multithreading.

What you write is an advantage of continuations compared to general 
coroutines. I consider that a very marginal advantage. Correctness is 
far, far more important than some micro-efficiency.

The advantage of general coroutines is that they enable multi-tasking 
(namely cooperative multi-tasking) without the severe synchronization 
problems of general threads or processes.

Coroutines don't automagically deal with all kinds of multi-tasking 
problems, in particular deadlocks are still possible, but you don't have 
two or more threads possibly accessing the same thing at a time, since 
only one coroutine executes at a time.


> In order to achieve this, language support is needed that was just not 
> available prior to C++20 (and even with C++20 such support is limited, 
> so that only the subset of continuations is actually available, as you say)

True, but I fail to see any reason, and I haven't yet seen anybody able 
to cough up a reason, to have continuations in C++.


> The point being, if you try to do that using threads kind of defeats the 
> purpose, doesn't it?

No (you misunderstood the purpose).

Doing this could open the world of safe multi-tasking to C++ programmers 
in general.

Oh, I already wrote that, sorry.


> (even if you build this with full synchronization inside, you'll still 
> pay the price of performance and resource usage, which can be relevant 
> for this kind of thing)

Yes, it must be built with synchronization inside, and like threads each 
general coroutine needs its own stack, which is another cost: firing up 
a general coroutine generally involves a dynamic allocation (though I 
guess with language support it's technically possible to use statically 
allocated stack areas when the number of coroutines has a reasonably low 
upper bound, but such support would be needed for that because standard 
threads don't provide any means to influence the per-thread stacks).


>> Another such enabler: an implementation of Ada-like rendezvous.
>>
>> And, and, ... Occam-like channels, maybe. :)

I forgot to mention Linda.

Oh well.


- Alf

[toc] | [prev] | [next] | [standalone]

#81604

On 9/26/2021 1:50 AM, Alf P. Steinbach wrote:
> On 25 Sep 2021 23:07, Manfred wrote:
>> On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
>>> On 20 Sep 2021 23:30, Lynn McGuire wrote:
>>>> "C++20 Coroutines" by Martin Bond
>>>>     https://blog.feabhas.com/2021/09/c20-coroutines/
>>>>
>>>> "There seems to be a lot of confusion around the implementation of 
>>>> C++20 coroutines, which I think is due to the draft technical 
>>>> specification for C++20 stating that coroutines are a work in 
>>>> progress so we can’t expect full compiler and library support at 
>>>> this point in time.
>>>> A lot of the problems probably arise from the lack of official 
>>>> documentation about working with coroutines. We have been given C++ 
>>>> syntax support for coroutines (the co_yield and co_return) but 
>>>> without all of what I consider full library support. The standard 
>>>> library has hooks and basic functionality for supporting coroutines, 
>>>> but we must incorporate this into our own classes. I anticipate that 
>>>> there will be full library support for generator style coroutines in 
>>>> C++23."
>>>
>>> The main confusion about C++20 “coroutines” is that they're general 
>>> coroutines.
>>>
>>> They're not: they're simple continuations, the special case of 
>>> /stackless/ coroutines (no dedicated stack for each coroutine).
>>>
>>> While that's nice performance-wise it's very limited, and the 
>>> Microsoft style support framework adopted in C++20 requires you to 
>>> build a full fledged star ship in order to lift a little pebble; 
>>> it's, well, moronic.
>>>
>>> ---
>>>
>>> I once started coding up real coroutines in terms of standard C++ 
>>> threads.
>>>
>>> That could be very useful, in contrast to the mostly useless C++17 
>>> continuations.
>>>
>>> However, I stopped fiddling with it when the complexity of the 
>>> implementation overwhelmed me. No doubt because of a lack of 
>>> experience in safe multi-tasking. It would be really nice if SOMEONE 
>>> could do this: real general coroutines, by leveraging real C++ threads.
>>>
>>> ---
>>>
>>> That could open the world of safe multi-tasking to C++ programmers in 
>>> general.
>>
>> I'm no expert in coroutines, but AFAIU their main advantage is to 
>> enable multitasking without the overhead of multithreading.
> 
> What you write is an advantage of continuations compared to general 
> coroutines. I consider that a very marginal advantage. Correctness is 
> far, far more important than some micro-efficiency.

Correctness is the precondition, obviously, but this is not about 
micro-efficiency (see below)

> 
> The advantage of general coroutines is that they enable multi-tasking 
> (namely cooperative multi-tasking) without the severe synchronization 
> problems of general threads or processes.

Yes, what you call "severe synchronization problems" is part of what I 
called "overhead". (I tend to write in a very concise way - that is 
meant both as "coding overhead" and "resource usage overhead")

> 
> Coroutines don't automagically deal with all kinds of multi-tasking 
> problems, in particular deadlocks are still possible, but you don't have 
> two or more threads possibly accessing the same thing at a time, since 
> only one coroutine executes at a time.

Yes, that was clear.

> 
> 
>> In order to achieve this, language support is needed that was just not 
>> available prior to C++20 (and even with C++20 such support is limited, 
>> so that only the subset of continuations is actually available, as you 
>> say)
> 
> True, but I fail to see any reason, and I haven't yet seen anybody able 
> to cough up a reason, to have continuations in C++.

Aren't continuations in C++20? Do you mean general coroutines?
If that is the case, the fact that POSIX has (had) support for them 
would suggest that it should be possible, then the fact that they 
dropped it may also suggest that there are counter indications of some 
sort, but I agree that still the question for explanation stands.

> 
> 
>> The point being, if you try to do that using threads kind of defeats 
>> the purpose, doesn't it?
> 
> No (you misunderstood the purpose).
Not entirely (see above)

> 
> Doing this could open the world of safe multi-tasking to C++ programmers 
> in general.
> 
> Oh, I already wrote that, sorry.
So, you mean make life easier for C++ programmers that are not 
comfortable with multithreaded programming, fair enough. ("open the 
world" sounded to me like there would be something more involved).

> 
> 
>> (even if you build this with full synchronization inside, you'll still 
>> pay the price of performance and resource usage, which can be relevant 
>> for this kind of thing)
> 
> Yes, it must be built with synchronization inside, and like threads each 
> general coroutine needs its own stack, which is another cost: firing up 
> a general coroutine generally involves a dynamic allocation (though I 
> guess with language support it's technically possible to use statically 
> allocated stack areas when the number of coroutines has a reasonably low 
> upper bound, but such support would be needed for that because standard 
> threads don't provide any means to influence the per-thread stacks).
> 
Referring to the first "see below" above: there are multiple performance 
costs involved with firing up multiple threads - whether these costs 
fall into the category of "micro-efficiency" depends on the context.

AFAIU coroutines are especially used (or at least advocated for) in 
areas like high-throughput server processes, real time systems, and 
architectures with strict resource constraints. This is why I wrote 
performance might be relevant for this kind of thing.

As to how it works, with POSIX I found "man makecontext" interesting (on 
any decent Linux box or the appropriate POSIX documentation).
But then, support for this has been removed in POSIX.1-2008, so probably 
it's not that pressing of a need.

> 
>>> Another such enabler: an implementation of Ada-like rendezvous.
>>>
>>> And, and, ... Occam-like channels, maybe. :)
> 
> I forgot to mention Linda.
> 
> Oh well.
> 
> 
> - Alf

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web