The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace. I've never tried it myself though.
BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber support. See Sinatra::Synchrony (https://github.com/kyledrake/sinatra-synchrony) and Goliath (http://www.igvita.com/2011/03/08/goliath-non-blocking-ruby-19-web-server/). They both work very well, with pure synchronous code style. Bryan On Apr 1, 2012, at 7:49 PM, Olivier Lalonde wrote: > > Many times I invoke something without a callback. > > I didn't think about this. It seems this problem would only affect "output" > functions. Not convinced it is a deal breaker yet, I'll try to come up with > some workarounds. > > > You know that you couldn't do anything async like serve web pages, right? > > I'm aware of that. Writing sync web apps would imply using one process/worker > by request like other popular languages do (PHP/Ruby/etc.). I think it is > still interesting to use Javascript for backend development even without the > async stuff. > > On Monday, April 2, 2012 10:20:01 AM UTC+8, Olivier Lalonde wrote: > I'm sorry if this has been discussed before, but I couldn't find anything. > This a modest proposal to introduce sync APIs in Node.js > > A lot of people would like to use Javascript for their web backend, but don't > want to program in an async style (I believe those reasons have already been > discussed at length). > > As it stands right now, it is practically impossible to program in Node.js in > a sync style, since most core modules and native extensions only provide an > async interface. > > I believe there would be an easy way to change the status quo without > impacting developers who chose to adhere to a strict async style. The > solution I propose is simply a pattern for writing I/O APIs: every I/O call > should be async unless no call back is supplied, in which case the I/O call > should be sync and use return / throw statements instead of calling a > callback. > > There is probably a flaw in my reasoning since I'm probably not the first one > to come up with this pattern. That being said, I think it would be an elegant > way to make both async/sync fans happy while keeping all the backend JS > community focused on one project rather than fragmenting the community in > multiple CommonJS server implementations. > > Thoughts? > > -- > 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
