Live data from Hacker News

Looking at Unity made me understand the point of C++ coroutines

mropert.github.io

181–190 of 190 posts

Re: Looking at Unity made me understand the point of C++ coroutines

#181

Earlier quoted context omitted.

Using shared_ptr everywhere is an antipattern. The whole point of controlling the capture is controlling the memory layout, which is what C++ is all about. Even with Asio, you don't really have to do this. It's just the style the examples follow, and Asio itself isn't necessarily the best design.

With callbacks you have to make sure that your data persists across the function calls. This necessarily requires more heap allocations (or copies) than in a coroutine where most data can just live on the stack.

A coroutine doesn't do anything more than a callback does -- it's just syntactic sugar.

The default behaviour of many asynchronous systems is to extend the lifetime of context data until all the asynchronous handlers have run. You can also just bind them to the resource instead which is arguably more elegant, but which depends on how cancellation is implemented.

Re: Looking at Unity made me understand the point of C++ coroutines

#182

Earlier quoted context omitted.

With callbacks you have to make sure that your data persists across the function calls. This necessarily requires more heap allocations (or copies) than in a coroutine where most data can just live on the stack.

A coroutine doesn't do anything more than a callback does -- it's just syntactic sugar. The default behaviour of many asynchronous systems is to extend the lifetime of context data until all the asynchronous handlers have run. You can also just bind them to the resource instead which is arguably more elegant, but which depends on how cancellation is implemented.

Any data that needs to survive across several callback invocations requires shared ownership. This means that the data must be allocated on the heap and probably also requires reference counting. With lambdas it's also easy to make mistakes, e.g. by capturing variables on the stack by reference.

In a coroutine everything can just live on the stack because the stack frame itself is kept alive across the asynchronous function calls.

Don't you see the big difference regarding lifetime management?

Re: Looking at Unity made me understand the point of C++ coroutines

#183

Earlier quoted context omitted.

A coroutine doesn't do anything more than a callback does -- it's just syntactic sugar. The default behaviour of many asynchronous systems is to extend the lifetime of context data until all the asynchronous handlers have run. You can also just bind them to the resource instead which is arguably more elegant, but which depends on how cancellation is implemented.

Any data that needs to survive across several callback invocations requires shared ownership. This means that the data must be allocated on the heap and probably also requires reference counting. With lambdas it's also easy to make mistakes, e.g. by capturing variables on the stack by reference. In a coroutine everything can just live on the stack because the stack frame itself is kept alive across the asynchronous f…

Not necessarily, I already explained how (resource binding).

Close the socket, all handlers are cancelled, context can be freed immediately. The socket owns the data.

Re: Looking at Unity made me understand the point of C++ coroutines

#184

Earlier quoted context omitted.

Any data that needs to survive across several callback invocations requires shared ownership. This means that the data must be allocated on the heap and probably also requires reference counting. With lambdas it's also easy to make mistakes, e.g. by capturing variables on the stack by reference. In a coroutine everything can just live on the stack because the stack frame itself is kept alive across the asynchronous f…

Not necessarily, I already explained how (resource binding). Close the socket, all handlers are cancelled, context can be freed immediately. The socket owns the data.

> The socket owns the data.

What if there's more than one socket involved?

Re: Looking at Unity made me understand the point of C++ coroutines

#185

Earlier quoted context omitted.

Not necessarily, I already explained how (resource binding). Close the socket, all handlers are cancelled, context can be freed immediately. The socket owns the data.

> The socket owns the data. What if there's more than one socket involved?

Then you have it owned by the parent which owns all relevant sockets.

Resource ownership management 101.

Re: Looking at Unity made me understand the point of C++ coroutines

#186

Earlier quoted context omitted.

> The socket owns the data. What if there's more than one socket involved?

Then you have it owned by the parent which owns all relevant sockets. Resource ownership management 101.

But that's not what you want. The context object should be freed when the associated operation finishes (either successfully or with an error), not when the parent goes out of scope. With coroutines I can simply put the context object on the stack and when the task finishes, the object automatically goes out of scope.

Re: Looking at Unity made me understand the point of C++ coroutines

#187

Earlier quoted context omitted.

I said used, as in used in your everyday life, by interacting with computer systems whose backend implementations you are blissfully ignorant of. But yeah, if you want to win arguments then arguing against yourself and your own hallucinations, is in your case the best way to go.

Um... you might want to look at my profile. In addition to working at MS and Apple for two decades (where I touched everything from firmware, ring-0, and ring-3), I was on the team that created SoftICE [0]: the first commercial ring-0 debugger for Windows. I also created the automated deadlock detector for BoundsChecker [1], which requires an in-depth understanding of operating system internals. > computer systems wh…

> You wrote a "C++ framework" that runs in the "backend" of a "computer system"? Do I have that right?

Probably not.

You seem to be struggling with technical language.

Re: Looking at Unity made me understand the point of C++ coroutines

#188

Earlier quoted context omitted.

Um... you might want to look at my profile. In addition to working at MS and Apple for two decades (where I touched everything from firmware, ring-0, and ring-3), I was on the team that created SoftICE [0]: the first commercial ring-0 debugger for Windows. I also created the automated deadlock detector for BoundsChecker [1], which requires an in-depth understanding of operating system internals. > computer systems wh…

> You wrote a "C++ framework" that runs in the "backend" of a "computer system"? Do I have that right? Probably not. You seem to be struggling with technical language.

See? I have no problem sharing/discussing what I've built. Throughout this entire thread they only thing you've done is bullshit. And again, remember that this started because you thought coroutines were "intimidating" while trying to mansplain how they worked to someone who literally built that functionality.

But sure... let's keep going while you do nothing but whine without displaying any technical acumen. This is fun!

Why don't you hop into the discussion of the early Windows ring-3-to-ring-0 transition issues [0] we had in the 90s? You know... since I am "blissfully ignorant" about internals. I can't wait to learn from your "backend" expertise!!

[0]: https://news.ycombinator.com/item?id=47611921#47612953

Re: Looking at Unity made me understand the point of C++ coroutines

#189

Earlier quoted context omitted.

> You wrote a "C++ framework" that runs in the "backend" of a "computer system"? Do I have that right? Probably not. You seem to be struggling with technical language.

See? I have no problem sharing/discussing what I've built. Throughout this entire thread they only thing you've done is bullshit. And again, remember that this started because you thought coroutines were "intimidating" while trying to mansplain how they worked to someone who literally built that functionality. But sure... let's keep going while you do nothing but whine without displaying any technical acumen. This is…

You do love your scare quotes, eh?

How old are you? 14?

Bye!

Re: Looking at Unity made me understand the point of C++ coroutines

#190

Earlier quoted context omitted.

See? I have no problem sharing/discussing what I've built. Throughout this entire thread they only thing you've done is bullshit. And again, remember that this started because you thought coroutines were "intimidating" while trying to mansplain how they worked to someone who literally built that functionality. But sure... let's keep going while you do nothing but whine without displaying any technical acumen. This is…

You do love your scare quotes, eh? How old are you? 14? Bye!

I'm the one trying to have a meaningful technical discussion with someone who finds a basic part of C++ intimidating.

One of us worked on two of the most popular development tools of all time, and the other makes shit up and refuses to engage with technical details.

Also, since you know what I've worked on, it should be pretty obvious how old I am.

Post reply on HN