Fibers and coroutines概念

Fiber(直译：纤维，这里light-weight-thread 纤程比较合适…)

           Coroutines(协同程序)

1.     Whatare fibers and why should you care?

非常好的一篇文章，介绍fiber

http://zeroturnaround.com/rebellabs/what-are-fibers-and-why-you-should-care/

2. How to Implementing coroutines in Java

First,what is coroutines?

Coroutines are computer program componentsthat generalize（概括） subroutines(子程序) for nonpreemptive(非抢占式的) multitasking, by allowing multiple entry(入口) pointsfor suspending and resuming execution at certain locations. Coroutines arewell-suited for implementing more familiar program components such ascooperative(合作的) tasks, exceptions, event loop, iterators, infinite lists andpipes.

According to Donald Knuth, the termcoroutine was coined by Melvin Conway in 1958, after he applied it toconstruction of an assembly program.[1] The first published explanation of thecoroutine appeared later, in 1963。

 

Distinct  language has distinct introduction and implementation，details see：

https://en.wikipedia.org/wiki/Coroutine

 

This question isrelated to my question on existing coroutine implementations in Java. If, as Isuspect, it turns out that there is no full implementation of coroutinescurrently available in Java, what would be required to implement them?

 

As I said in thatquestion, I know about the following:

 

You can implement"coroutines" as threads/thread pools behind the scenes.

You can do tricksy(狡猾的) things with JVM bytecode behind thescenes to make coroutines possible.

The so-called"Da Vinci Machine" JVM implementation has primitives that makecoroutines doable without bytecode manipulation(控制).

There are variousJNI-based approaches(方法,路径) to coroutines also possible.

I'll address eachone's deficiencies in turn.

 

Thread-basedcoroutines

 

This"solution" is pathological(极端的，病态的). The whole point of coroutines is to avoid theoverhead of threading, locking, kernel scheduling, etc. Coroutines are supposedto be light and fast and to execute only in user space. Implementing them interms of full-tilt threads with tight restrictions gets rid of all theadvantages.

 

JVM bytecodemanipulation

 

This solution ismore practical(注重实际的), albeit(虽然) a bit difficult to pull off(完成). This is roughly(大体,大致上) the same as jumping down into assembly language forcoroutine libraries in C (which is how many of them work) with the advantagethat you have only one architecture to worry about and get right.

 

It also ties youdown to only running your code on fully-compliant JVM stacks (which means, forexample, no Android) unless you can find a way to do the same thing on thenon-compliant stack. If you do find a way to do this, however, you have nowdoubled your system complexity(复杂性) and testing needs.

 

The Da VinciMachine(build a patched JVM Machine)

 

The Da VinciMachine is cool for experimentation, but since it is not a standard JVM itsfeatures aren't going to be available everywhere. Indeed I suspect mostproduction environments would specifically forbid the use of the Da VinciMachine. Thus I could use this to make cool experiments but not for any code Iexpect to release to the real world.

 

This also has theadded problem similar to the JVM bytecode manipulation solution above: won'twork on alternative stacks (like Android's).

 

JNI implementation

 

This solution renders the point of doing this inJava at all moot. Each combination of CPU and operating system requiresindependent testing and each is a point of potentially frustrating subtlefailure. Alternatively, of course, I could tie myself down to one platformentirely but this, too, makes the point of doing things in Java entirely moot.