Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The async library #55

Open
alcuadrado opened this issue Jul 23, 2019 · 4 comments
Open

The async library #55

alcuadrado opened this issue Jul 23, 2019 · 4 comments

Comments

@alcuadrado
Copy link
Member

This another meta-issue on how to improve IMO the state of ethereumjs in general.

Most libraries use the npm package async. This was kind of standard practice in the node.js community many years ago, but that's no longer the case.

Code written with this library is hard to read and maintain, and I believe it prevents new people from collaborating. Take a look at this function for a clear example of how scary it can get.

Personal preferences apart, this library prevents v8 from creating async stack traces. These were released (enabled by default) in node 12. For them to work, you have to stick to async/await. If you don't, this feature removes some internal (e.g. process._tickcallback calls) stack frames, leaving an almost empty (even emptier than before!) stack trace.

I know this is a huge change, but I believe it's important.

I think a good way to start working on this can be migrating the tests from a library. For example, ethereumjs-blockchain's test.

@holgerd77
Copy link
Member

@alcuadrado Sina already removed most (all?) usages of the async package during the VM refactoring, so getting to consensus here should be relatively straight-forward. This was mostly in the runXXX.ts execution files if you want to have a look for inspiration, see e.g. runBlock.ts vs runBlock.js (a bit hard to compare since history broke along with the TypeScript changes, I just used an old branch with the js files for this to compare manually).

This sounds highly obvious to me with a huge structural win both on the readability and debuggability side, so I think taking some effort here is very much worth it.

@evertonfraga
Copy link
Contributor

Just to keep this warm and help whoever wants to contribute here. Those are the remaining uses of the async lib:

File Code
blockchain/test/index.ts:33 async.parallel(
blockchain/test/index.ts:631 async.series(
blockchain/test/index.ts:683 async.series(
blockchain/test/index.ts:732 async.series(
blockchain/test/index.ts:793 async.series(
blockchain/test/index.ts:801 async.series(
blockchain/test/index.ts:837 async.series(
blockchain/test/index.ts:897 async.eachOfSeries(
blockchain/src/index.ts:260 async.waterfall(
blockchain/src/index.ts:392 async.eachSeries(
blockchain/src/index.ts:424 async.eachSeries(
blockchain/src/index.ts:471 async.series(
blockchain/src/index.ts:511 async.parallel(
blockchain/src/index.ts:594 async.parallel(
blockchain/src/index.ts:708 async.whilst(
blockchain/src/index.ts:915 async.series(
blockchain/src/index.ts:1047 async.whilst(
blockchain/src/index.ts:1057 async.series([getBlock, runFunc), function(err?: any) {
vm/tests/util.js:44 async.mapSeries(
vm/tests/util.js:129 var q = async.queue(function(task, cb2) {
vm/tests/util.js:371 async.eachSeries(
vm/tests/util.js:384 async.series(
vm/tests/util.js:389 async.forEachSeries(
vm/tests/BlockchainTestsRunner.js:53 async.series([
vm/tests/BlockchainTestsRunner.js:74 async.eachSeries(testData.blocks, function (raw, cb) {
vm/tests/GeneralStateTestsRunner.js:49 async.series([
vm/tests/GeneralStateTestsRunner.js:115 async.series([
vm/tests/GeneralStateTestsRunner.js:151 async.eachSeries(testCases,
vm/tests/VMTestsRunner.js:14 async.series([
vm/lib/runBlockchain.ts:26 async.series([getStartingState, runBlock), cb)

@holgerd77
Copy link
Member

The merkle tree library is also a heavy async user, see e.g. here.

@holgerd77
Copy link
Member

Not sure if there are still occurrences here, will keep this open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants