Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by rafl (7583) on 2009.07.04 23:45 (#69258)

    Yes, currently you will have to explicitly cede control to the other coroutines regularly. However, Yuval is currently trying to get his patch [github.com] implementing preemptive coros merged into Coro. Those allow control to be automatically passed to other Coros using different strategies like opcode counting and fixed timeslices. That'd at least solve one of the problems you're describing.

    • That would totally make me reconsider things. Thanks for pointing this out!

    • Of course, by making coroutines actually execute in parallel, you give up the one thing that Coro provides over threads - you invite back in the daemons of locking and deadlocks.

      • Luckily, preemptive coros don't do that. Everything still runs in one process, one coro at a time. Just passing control from one coro to another can happen implicitly, so blocking code that isn't under your control is not a problem anymore.

    • Excuse my gross ignorance, but would this remove the one-core limit?

      Could we then use even half of my four core machine?

      • This would totally not remove the one-core limit. But it would fix essentially all other problems. For multi-core usage, one would have to resort to an extra process.