On 11/17/2015 07:47 PM, Aus Lacroix wrote:
Even though this is the case, we recognize that synchronous tcp socket
usage isn't ideal (we didn't think it was in the first place,
necessarily, it was just the best way to make the tests easy to write).
Do we have a mitigation plan in place as we move towards full-async and
promises? One of the nice things about the (ugly) synchronous-TCP-use
in Marionette JS and the old-school mozmill (ugly) nested event loop
spinning (from inside the gecko process on the main thread) was that
they were foolproof from a control flow perspective. You couldn't
forget to yield on a Promise or otherwise fail to wait for the async
thing you just requested to complete.
Marionette JS has the advantage that it mediates all interaction with
the Gecko process so it can ensure that operations occur in order, but
it might be advantageous for it to return promises that insta-fail the
test if the returned Promise does not have then() called on it before
control flow is yielded.
This type of promise isn't something one could use without false
positives/explosions in non-testing code[1], but it seems like it would
be a good way to keep everyone sane. Specifically, if using a driver
like https://github.com/tj/co that can do generator.throw() when a
yielded Promise rejects, it helps keep line numbers and call stacks
sane. It also helps ensure that calls to console.log() don't end up
misleading as control-flow races ahead of where Marionette is at. It
also is beneficial for tests that involve processes other than Gecko,
such as fake HTTP or email servers. (Versus the case where Marionette
JS is super-smart and has its secret queue of pending operations.)
Andrew
1: See discussions on enabling promise debugging related to done() and
others. Some starting points for those interested:
https://github.com/domenic/promises-unwrapping/issues/19
https://code.google.com/p/v8/issues/detail?id=3093
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
