Skip to content

Comment on An open question (rant) about Node.jsparent

Comments

I wrote a post on this in a Go topic here not too long ago:

https://news.ycombinator.com/item?id=7388790

It was about how essentially, in a large concurrent system, a chain of callbacks like:

cb1 -> cb2 -> cb3|eb3 then cb3->cb4 and eb3->cb5

(select/epoll returns and calls cb1, chain ends with cb4 or cb5 depending if errback eb3 is called).

Is just a messy, dangerous and confusing re-implementation of threads/goroutines/tasks. Besides spreading the business logic among multiple io related function or sprinkling yields() or thens() it doesn't completely save one from needing locks and semaphores if shared or non-local data is modified.

A second callback chain from cb1 could have started before the previous one finished. Now they both could be modifying the same data. Yes granularity level in this is at code block level between IO points not assembly instruction, as the system grows large this problems becomes apparent.

I had to deal with it in a Python Twisted based framework. There is Twisted Semaphore and I had to use it.

The node.js and reactor-based event loops look _very_ nice in small demos and when the callback chain is shallow. HAproxy or nginx are good examples of this. They have shallow callback chain. Node.js demo example also look good, "Oh look you can serve 'Hello World' in 5 lines on a websocket!'" stuff like that.

As systems grow larger, callbacks chains as concurrency mechanisms start to suck.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.