It's about not wanting to be forced to do everything just one way, because the framework is incompatible with any other way of working.
And that's exactly why I like Coro. The other choices for event-driven development take away extremely useful tools (catching exceptions, stack traces) and pollute every tiny bit of code with the need to write the code much differently. Coro only requires that the exact points where blocking might happen be tweaked to make Coro aware of the blocking and those changes are usually pretty easy to make. The rest of your code shows no evidence of Coro being used.
Yes, a single Coro instance won't use multiple cores. That has never been an issue in the projects I've considered Coro for because either they need to scale so I plan on running multiple instances anyway or they don't in which case one core is enough and the other core(s) get used by other stuff. Yes, there are cases where you don't want multiple instances and yet do want to use multiple cores but don't need more cores than are in the one computer you are using, and Coro would not be the best choice in such a constrained situation.
I find that threading can be very useful in the simplest of cases. But having spent years writing multi-threaded code with a group of people who were very good at it, I believe that scaling via threading is nearly a doomed endeavor. My experience is that the vast majority of programmers are quite bad at identifying race conditions. They are even worse at preventing race conditions. And they are worse still at both of those tasks when threads are involved. And even the best programmers can't keep a long-lived, significantly upgraded system free of serious problems associated with using threads.
IME, I'm pretty good at those tasks. And I'd still rather just avoid dealing with them as much as possible. Adding real threads (not what Perl 5 currently calls "threads") means that you have race conditions to consider all over the place. Perl's "threads" came to be because no Perl porter was able to remove the race conditions from trying to use real threads with Perl. So they switched to using threads to emulate fork() but much less efficiently in both memory and CPU required. So I prefer real fork over emulated fork. On Windows, I tend to either use cygwin or use spawn to emulate fork.
I've not used Perl "threads" under Windows even for simple tasks because every time I've tried I've found bugs almost immediately. Lots of people say that is no longer going to happen but then they said that lots of previous times when I still found bugs almost immediately.
I consider Perl "threads" under Windows for simple tasks and so will likely try again at some point. But I strongly avoid threads in a project that will need to scale either to running many instances or (more importantly) to having an extended lifespan of active development and enhancement.
And I've seen many projects start out just fine using threads and then have an ever-increasing set of problems with race conditions, deadlocks, and lack of concurrency. And those problems are rather fundamental.
I'd love to see a very general-purpose framework for preventing race conditions that also prevents deadlocks and reduced concurrency. I don't think one has been invented yet other than the very successful framework of a preemptive-multitasking operating system using processes with segregated resources. When the overhead per process becomes a problem (as can happen with Perl), I think coroutines present the best available long-term solution by allowing one process and one Perl interpreter to handle a large number of simultaneous tasks with only minimal coroutine-specific code. And it looks like Coro is a good implementation of coroutines for Perl.
- tye
In reply to Re^5: Your main event may be another's side-show. (Coro)
by tye
in thread Your main event may be another's side-show.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |