V8 Fibers in nodejs?

223 views
Skip to first unread message

Egor Egorov

unread,
Jan 18, 2011, 6:20:49 PM1/18/11
to nod...@googlegroups.com
I saw that v8cgi project has Fibers implementation in their code: http://code.google.com/p/v8cgi/source/browse/#svn%2Ftrunk%2Fsrc%2Flib%2Ffibers

Did anyone tried to port it to node.js? I tried but I have limited C++ knowledge and had no success. And, after all, would this feature be feasible in node.js? 

Guido Tapia

unread,
Jan 19, 2011, 2:16:03 AM1/19/11
to nodejs
Please excuse my ignorance but how can you have fibers without
threads? Arent fibers just code managed parallel execution units
(hence relying on threads)?

I did the Google but didn't get very far (fiber is kind of a crappy
name), is there any info on V8 fibers implementation anywhere?

Do fibers expose underlying threads? Sounds really interesting.

On Jan 19, 10:20 am, Egor Egorov <egor.ego...@gmail.com> wrote:
> I saw that v8cgi project has Fibers implementation in their
> code:http://code.google.com/p/v8cgi/source/browse/#svn%2Ftrunk%2Fsrc%2Flib...

Arnout Kazemier

unread,
Jan 19, 2011, 2:40:07 AM1/19/11
to nod...@googlegroups.com
Did you read:
http://en.wikipedia.org/wiki/Fiber_(computer_science)
http://en.wikipedia.org/wiki/Thread_(computer_science)#Processes.2C_kernel_threads.2C_user_threads.2C_and_fibers

And also see asana's blog post: http://asana.com/2010/10/adding-fibers-to-v8-efficiency-clarity-in-ssjs/

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>

Egor Egorov

unread,
Jan 19, 2011, 7:54:47 AM1/19/11
to nod...@googlegroups.com
V8 Fibers are "fake threads". Not a performance thing but rather just a kind of syntax sugar that helps eliminate some of the troubles of async programming. 

Vyacheslav Egorov

unread,
Jan 19, 2011, 8:11:31 AM1/19/11
to nod...@googlegroups.com
They are not "fake threads" neither they are lightweight --- they are
actually implemented with a real threads.

--
Vyacheslav Egorov

Egor Egorov

unread,
Jan 19, 2011, 8:35:27 AM1/19/11
to nod...@googlegroups.com
Oh! My mistake then. 

In this case I think they're surely going to be useful to node.js community, aren't they? 

Vyacheslav Egorov

unread,
Jan 19, 2011, 9:09:25 AM1/19/11
to nod...@googlegroups.com
Small clarification (I might have misunderstood what do you mean under
"fake threads"): V8 does not support preemptive multi-tasking, you
can't have several threads simultaneously executing JavaScript code.
[V8 Isolates branch provides a way to execute several completely
isolated share-nothing JavaScript threads simultaneously].

V8 supports cooperative multi-tasking where several "threads" share
the same VM cooperatively. Only one "thread" can be running in the
same time and running fiber has full control over VM (others can't
steal control unless running one decides to suspend itself). V8 Fibers
simply expose this capability to JavaScript code.

What I wanted to say by my previous message is that V8 Fibers are
implemented on top of real OS threads and use OS synchronization
primitives to schedule execution. This incurs overhead bigger than
that of the real green threads.

--
Vyacheslav Egorov

Guido Tapia

unread,
Jan 19, 2011, 1:36:46 PM1/19/11
to nodejs
In other words. Fibers are an expensive type of control flow that give
you no performance benefit. Sounds useful.

Sorry bout the sarcasm but for a second I thought this was a way of
opening up node to the data analysis/visualization market (which is
where I live). Disappointing.

Guido

Dean Landolt

unread,
Jan 19, 2011, 2:12:43 PM1/19/11
to nod...@googlegroups.com
On Wed, Jan 19, 2011 at 1:36 PM, Guido Tapia <guido...@gmail.com> wrote:
In other words. Fibers are an expensive type of control flow that give
you no performance benefit. Sounds useful.

Sorry bout the sarcasm but for a second I thought this was a way of
opening up node to the data analysis/visualization market (which is
where I live). Disappointing.


Are you suggesting the only way to do data analysis/visualization is with shared state concurrency? Why would that be?

Guido Tapia

unread,
Jan 19, 2011, 2:43:51 PM1/19/11
to nodejs
Visualization or analysis of large data sets is CPU intensive, can
take a while (my system up to 1min). You cannot have a single
threaded server blocking for that long.

On Jan 20, 6:12 am, Dean Landolt <d...@deanlandolt.com> wrote:

Tim Caswell

unread,
Jan 19, 2011, 3:17:41 PM1/19/11
to nod...@googlegroups.com
What's wrong with running the expensive analysis in another process (or few) and using IPC to shuttle the request and results back and forth?

Ryan Dahl

unread,
Jan 19, 2011, 3:19:28 PM1/19/11
to nod...@googlegroups.com
On Wed, Jan 19, 2011 at 11:43 AM, Guido Tapia <guido...@gmail.com> wrote:
> Visualization or analysis of large data sets is CPU intensive, can
> take a while (my system up to 1min).  You cannot have a single
> threaded server blocking for that long.

Use more than one...

Reply all
Reply to author
Forward
0 new messages