Re^12: Your main event may be another's side-show. (Coro)

[BrowserUk]

Well, there you misunderstand Coro. No such fiddling is required. You are thinking of your prior experience with cooperative multi-tasking operating systems, not of using cooperative multi-tasking within a process that is part of a modern operating system.

And there it is. Magic bullet claims, and excuses for why you can't demonstrate it.

A coroutine program that never yields, (Coro code that doesn't cede), is not cooperative-anything nor multi-anything. It's a single tasking process, and you (well I at least), don't need coroutines to write those!

The moment you put two coroutines into the same program, (and the clue that this is the norm is is the "Co" part--you can't have co-operation between a single routine), then they have to yield periodically otherwise only one ever does anything.

I didn't ask you to post megabytes of your work code. But if you have the time to write the above post, you certainly have time to code a simple demonstration of the basic control and dataflows. At least you would if you used threads, but maybe Coro code is so complicated it really would take lots of effort?

But that is the history of this debate. Always ready with the words, but never the code.

If that escape clause means that you are only interested in purely computation-bound operations,

No, it doesn't. It means that I recognise that there are some applications for which threads are not the best option. And large fan-out, autonomous communications servers are one such application. But I also recognise that only a small percentage of applications fit that scenario.

And that the large majority of applications that come up here, involve a mix of IO-bound and cpu-bound tasks. And that threading accommodates this easily where, event-driven frameworks don't. So, for your average punter here seeking to hive off a little cpu-bound processing whilst remaining responsive to other things; or seeking to cut his runtime by utilising his multiple cores to perform cpu-intensive algorithms on a large dataset, threads are the far simpler option to the often suggested, (but never demo'd), event-driven framework behemoths.

Why are you, and many like you, so scared of comparing like with like?

[tye]

And there it is. Magic bullet claims

*sigh* You misunderstand again.

Why are you, and many like you, so scared of comparing like with like?

Yes, I'm quite terrified. *plonk*

Have fun.

[BrowserUk]

*sigh* You misunderstand again.

If I misunderstand--and I don't think I do--its because your descriptions (despite their verbosity(*)), are lacking.

But then, we all know the best description of code, is the code itself.

(*)If you left out the attempts at snide put-downs, you'd perhaps make a better fist of your descriptions.

Ps. This is how quick it is to knock up a PoC.

[tye]

Read more... (353 Bytes)

Thanks for mentioning that, though. It makes some of your reactions easier to understand.

Read more... (3 kB)

But then, we all know the best description of code, is the code itself.

The "code itself" (for any of the cases I'm talking about) is many tens of thousands of lines and so makes for quite a horrid "description", actually. It is nice that you find it extremely easy to make short mock-ups in code that you find adequately convey a complex situation that you are trying to describe. I find quick mock-ups very often end up with the "quick" part being relatively quick but that the "last 10%" (of actually making it work and thus be useful as an example) can take even more than the fabled "90% of the time". So I don't embark on such time sinks for myself much.

And then there are tons of details in working code that can't be "glossed over" and so figuring out what the point of the mock-up was from reading the code is often not an obvious step for me. So I probably wouldn't understand your discussion in the form of code any better than you understand me. C'est la vie.