guarantee function execution order of parallel

[bahamas10]

When running functions using vasync.parallel can we make the guarantee that the functions will be executed in the order they are passed in? I know that they will be executed in parallel without waiting for any of the previous functions executions to finish, but can the guarantee be made that the functions will execute in the order of the funcs array?

Looking at the implementation the logic executes the functions in the order they were passed in so this currently is the case.

	for (i = 0; i < funcs.length; i++) {
		rv['operations'][i] = {
			'func': funcs[i],
			'funcname': funcs[i].name || '(anon)',
			'status': 'pending'
		};

		funcs[i](doneOne(rv['operations'][i]));
	}

I would just like to see this be made a feature and added to the documentation as something that will be supported and guaranteed not to change.

For example:

var vasync = require('vasync');

var i = 0;
vasync.parallel({funcs: [
    function funcOne(cb) {
        console.log('one: %d', ++i);
        cb();
    },
    function funcTwo(cb) {
        console.log('two: %d', ++i);
        cb();
    },
    function funcThree(cb) {
        console.log('three: %d', ++i);
        cb();
    }
]}, function done() {
    console.log('done: %d', ++i);
});

I would expect them to execute in the order funcOne, funcTwo, funcThree:

$ node parallel.js
one: 1
two: 2
three: 3
done: 4

This was first brought up by @joshwilsdon on the vminfod review here https://cr.joyent.us/#/c/2782/8/src/vm/node_modules/VM.js@7433

Josh: when doing these in parallel, are we guaranteed that the watcher will be ready before the makeIndestructible() does its business in all cases? Dave: So that's an interesting point. watchForEvent is synchronous, in that the watcher is already created, and the call to watchForEvent just attaches a listener. The only way this could break is if vasync.parallel for some reason decided to run the second function first... I actually don't know if parallel guarantees it'll run them in order. Josh: Might be worth checking, or at least documenting that this is the assumption.

[davepacheco]

I can see that. It's a tough call. I'd prefer to leave this unspecified, and in the example you linked to, the fact that the result would be correct seems pretty subtle. Would a barrier be a clearer way to do that?