Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-04-27:

[21:55] <devinus> goddamnit why are we arguing about sync/async
[21:55] <deanlandolt> heh
[21:57] <ashb> cos ryan is opinionated
[21:58] <devinus> why can't both be implemented
[21:58] <ashb> cos Sync Is Wrong clearly
[21:59] <devinus> ashb: but node already has sync alternatives
[21:59] <devinus> ashb: readDir/readDirSync etc
[21:59] <ashb> it still has them?
[21:59] <devinus> ashb: afaik
[21:59] <ashb> nothing seems to last long in node. there certainly isn't *any* concern for backcompat
[22:00] <devinus> ashb: yep. every async IO operation has a sync alternative
[22:00] <devinus> if the standard specified stuff like readDir/readDirSync i would be happy with that
[22:04] <devinus> but i swear to god
[22:04] <devinus> if there is only sync methods to shit i will bust a cap
[22:05] <kriskowal> Good. I can feel your anger.
[22:05] <kriskowal> Something something something dark side.
[22:06] <kriskowal> Something something something *complete*.
[22:06] <kriskowal> but seriously people, write proposals. it's a wiki.
[22:08] <devinus> kriskowal: i just....i just can't go back to the world of Python/Ruby i came from. if i fucking put sqlalchemy in a separate thread blah blah blah to get twisted to have async pg queries one more time....
[22:08] <kriskowal> yeah, i'm there man.
[22:08] <devinus> just cant do it anymore
[22:09] <kriskowal> sync vs async is just a false dilemma.
[22:09] * devinus nods
[22:10] <ashb> the thing i dont get is why you can't implement the sync alternatives like: { var r,done=false; x.cb(fun(res) { r=res; done=true;}) while (!done) runEventLoopOnce(); return r }
[22:10] <kriskowal> not having an async api for everything you need to do is obviously a problem. sync doesn't preclude creating async apis. async apis preclude the use of sync apis. it's not that complicated.
[22:10] <deanlandolt> kriskowal: i disagree...it can be (with promises) but API patterns diverge pretty quick w/ things like event emitters
[22:10] <kriskowal> ashb, yeah you can't do that.
[22:11] <ashb> kriskowal: because?
[22:11] <deanlandolt> kriskowal: ah, yes, i see what you mean...indeed
[22:12] <kriskowal> because the innermost loop needs to yield to the OS when no further events have been queued and all future events depend on IO. it needs to ask the OS to sleep until *any* of the pending IO events are possible. that means you need holistic handling of all timers and IO at the innermost loop of an async system.
[22:12] <devinus> maybe i'm fucking retarded (big possibility) but why can't everyone just do what node does and had a "Sync" appended function for any api ? are there implementers out there who jsut refuse to do any async at all ?
[22:13] <konobi> api.sync.function()... api.async.function()...
[22:13] <ashb> devinus: some platforms just can't have async
[22:13] <ashb> kriskowal: mixing timers and IO into a single select/epoll/etc is possible...
[22:13] <devinus> i guess if you never thought of async at all for your implementation then you'll be out of luck
[22:14] <kriskowal> yes. it is. that's what node does anyway. what are you arguing again?
[22:14] <devinus> ashb: which platforms?
[22:14] <ashb> devinus: Google App Engine, Joyent's Smart platform
[22:14] <ashb> kriskowal: why can't you just pump the event loop until the thing oyu are interested in is done
[22:15] <kriskowal> oh, deadlock.
[22:15] <ashb> and then return what got passed to your callback
[22:15] <kriskowal> nested event loops are problematic
[22:15] <ashb> because?
[22:16] <ashb> pretend like i'm the idiot i clearly am and spell it out for me
[22:19] <kriskowal> pretend i left my lecture notes at home for a moment
[22:26] <ashb> the only thing i can find about it is 'it might break some code if its not expecting re-entrant or blow the stack'
[22:26] <ashb> and blowing the stack is hardly special in this case

 

 

Logs by date :