Fiber abstraction needed?

[ComFreek]

The readme of node-fibers suggests to create an abstraction layer:

The examples below describe basic use of Fiber , but note that it is not recommended to use Fiber without an abstraction in between your code and fibers. See "FUTURES" below for additional information.

_{— source: https://github.com/laverdet/node-fibers#sleep}

Fortunately, Fibers is (yet) only used in index.js and in core files (in the code base of my PR). "User land code" should ideally never require Fiber calls.

[dancrumb]

I'm going to look into a small abstraction layer to handle process start and fiber yields together

[dancrumb]

I think this is done with #74

What do you think?

[jpaulm]

Not really sure what @ComFreek was trying to encapsulate - I didn't think
there were any other possible implementations...?

On Tue, Jun 7, 2016 at 6:30 PM, Dan Rumney [email protected] wrote:

I think this is done with #74 #74

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AATGJx5ZjumH74zyszplaXjnPDaV3xXqks5qJfDqgaJpZM4DfLSe
.

[ComFreek]

As far as I remember, I wanted to insert an abstraction between the network code itself (component functions) and the runtime. This would give more flexibility when switching runtimes, especially between Fiber-like runtimes and generator runtimes (@dancrumb maybe you have seen some traces of it in the code base).
However, the problem was that generators required the use of the async function modifier and the yield statement in component functions, which could not be abstracted away (due to language restrictions, these are actual "syntactic elements"), so that they are hidden behind a simple inputPort.get() - both in the fiber runtime and the generator runtime.

In conclusion, I think this issue should be closed as there is currently no viable solution to overcome the language restrictions mentioned above. Apart from that, the current copier.js looks as 'abstracted' as it is probably achievable!