Le samedi 10 novembre 2012 01:12:18 UTC+1, Alexey Petrushin a écrit :
> Why there are so many negative responses about fibers?
>
Using fibers (or threads) is not always as easy at it first seems. When
things get complex, issues like race conditions and deadlocks sometimes
become really hard to debug.
Sticking to the "single thread event loop + callbacks" of Javascript is
respectable "safe" option, with well known drawbacks.
This whole "fibers vs callback" stuff reminds me of what happened with
"remote objects". There were attempts to "hide" the "remote nature" of
remote objects, to make them look like "local objects", typically using
"proxi objects". This is still a popular option. However, the failure of
solutions like Corba, Soap or java's wsdl, is a clear indication that
"hiding" the remote nature of remote objects does not work so well in
practice. "ro.xx()" looks nice but does not deal so well with network
issues (timeouts, deconnections/reconnections, retries, etc).
Fibers are a similar attempt to "hide" the asynchronous nature of some
functions. It looks nice but does not deal so well
with synchronization issues. However things can get better if some higher
level lib is used to handle these issues.
But this is true with callbacks too. There are a lot of "flow
control libraries" available.
As a matter of fact I am developing one right now. It should look familiar
to those used to similar libraries based on threads.
With this lib, the "infamous" "pipe" example from the start of this google
thread looks like this:
function pipe( inStream, outStream, callback ){
l8.begin
.repeat( function(){ l8
.step( function(){ inStream.read( l8.next) })
.step( function( err, data ){
if( err ) throw err;
if( !data) l8.break;
outStream.write( data, l8.next);
})
.step( function( err ){ if( err ) throw err; })
})
.success( function(){ callback() })
.failure( function( err ){ callback( err) })
.end}
It's nicer using CoffeeScript:
pipe = l8.scope (in,out,cb) ->
@repeat ->
@step -> in.read @next
@step (err, data) ->
throw err if err
@break if !data
out.write data, @next
@step (err) -> throw err if err
@success -> cb()
@failure -> cb @error
This is not the shortest version ever published, yet it is reasonably
readable and does not try to "hide" the asynchronous nature of .read() &
.write()
More details here: https://github.com/JeanHuguesRobert/l8
My lib is not ready yet, but I am sure that you can find some other
ones easily.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
