I think that this trampoline approach makes sense and would well mesh with asynchronous IO and "green" (userspace) threads as Coro implements them:
Once your central code dispatcher (GCD) runs out of idle CPU cores/worker threads, it doesn't dispatch function calls by launching a new native thread but suspends the currently executing context and switches to another context using the method that Coro employs, switching out the (relevant part of the) C stack for another. This would basically be transparent to the main code, except for the drawback that parallel execution means more race conditions. When using Coro alone, you don't get nasty race conditions, because there is no parallel execution of Perl code. But you're not worse off than with plain threads.
The small problem that remains is that threads and Coro are unlikely to mix well. Coro itself claims that it is not iThread-safe, and I have little doubt that this is a false claim. and I have no reason to believe otherwise. I presume one of the more interesting problems will be how to move one coroutine context (basically a copy of the C or Perl call stack) across thread stack boundaries without messing up too many things. But maybe reusing the ideas (and clever macros, and development research) of Coro gives enough foothold to implement transparent switching between green and native threads.
Update: Clarified sentence about my impression how badly Coro and threads interact.
In reply to Re^5: [OT]: threading recursive subroutines.
by Corion
in thread [OT]: threading recursive subroutines.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |