> When things get complex, issues like race conditions and deadlocks sometimes become really hard to debug.
Race conditions and deadlocks are not a pitfall of cooperative multitasking. There are plenty of legit reasons to not use Fibers but I don't think this is one of them. On Fri, Nov 9, 2012 at 7:47 PM, JeanHuguesRobert <[email protected] > wrote: > 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 > -- 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
