The biggest problem with Coro is the bullshit factor.
Coro - the only real threads in perl
Bullshit! See last element below.
Unlike the so-called "Perl threads" (which are not actually real threads but only the windows process emulation (see section of same name for more details) ported to unix, and as such act as processes)
As is this.
They are "actually real threads". Real, kernel scheduled, core concurrent, execution contexts. (One use of which on Windows, is to emulate fork).
And the segregated address space, despite the limitations, allows Perl threads to avoid the main "problem" with threads in other languages: that of unintentional sharing of thread-scoped data.
A parallel matrix multiplication benchmark runs over 300 times faster on a single core than perl's pseudo-threads on a quad core using all four cores.
As is this.
See Re^6: If I am tied to a db and I join a thread, program chrashes for why the benchmark is a totally broken piece of marketing hype that serves little purpose beyond forwarding an agenda.
In this module, a thread is defined as "callchain + lexical variables + some package variables + C stack),
As is this.
Contrast that definition of "thread" with that from wikipedia: In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system.
My emphasis.
And the first three words do not justify this flagrant mis-definition. It's like calling a stately home (or The Whitehouse) an aeroplane, because they both have wings.
Coro's event's don't scale across cores. And cores are now both ubiquitous; and the only way to maintain Moore's Law going forward.
In reply to Re: Why Coro?
by BrowserUk
in thread Why Coro?
by xiaoyafeng
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |