Re^3: A suicidal parent OR death of a forking server

Instead of implementing a limited cooperative multitasking system using select, it's simpler to use ... Coro.

But what you've posted here is just as limited as the select version (that you also posted). It's not multi-tasking, Just cooperative time-sharing.

It suffers from all the same limitations and caveats as the select implementation, except that they are stuffed under the cover of a "pretty interface".

Limitations that include:

The inability to scale across multiple cores.
The need to break up cpu-intensive processing into "bite-sized chunks".

Yester~~days~~ ~~years~~ decades solution masquerading as something new, that headlines with what is both a factual and technical lie.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Comment on Re^3: A suicidal parent OR death of a forking server

Replies are listed 'Best First'.
Re^4: A suicidal parent OR death of a forking server by ikegami (Patriarch) on Jun 10, 2010 at 04:17 UTC
Simply put, you don't need to save your entire state manually between blocking calls. That's a huge difference if you ask me. If one hits the limits of Coro or needs multiple cores, one can easily switch to thread, forks or `fork`.	[reply] [d/l]
Re^4: A suicidal parent OR death of a forking server by ikegami (Patriarch) on Jun 10, 2010 at 04:24 UTC
I have been advertising the fact that Coro only provides cooperative multitasking, so no news. What's wrong with using the appropriate tool for the job? I could easily have used threads, forks or `fork` — two of those would simply require the addition of `->detach` — but since there was no requirement for that overhead, I used the lightweight solution.	[reply] [d/l] [select]