Rework Mozmill's sleep/waitFor methods to not spin the event loop



7 years ago
3 years ago


(Reporter: whimboo, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)

At the moment bug 789773 is causing us real pain because it end up in an application disconnect failure for Mozmill. Not sure if it is the zombie process which is getting created or something else in handling compartments but at some point the execution stops inside the thread.processNextEvent() call.

To give you some more details on that: In Mozmill we synchronize test steps and therefore we need methods like sleep() or waitFor() which let our code wait until a specified condition has been set. The code looks like:

function sleep(milliseconds) {
  var timeup = false;

  hwindow.setTimeout(function () { timeup = true; }, milliseconds);
  var thread = Cc[";1"]
  while (!timeup) {

As I have heard from Boris and Gavin a couple of months ago it's probably not a good way to do. So I'm seeking out now for advise how we can make this better.

I hope that with such a change we also have a chance to get the application disconnect sorted out. I would appreciate the feedback from each of you! Thanks!
It's worth keeping in mind that bug 789773 manifests in a zombie state because our underlying C++ appshell code actually spins the event loop while creating a top-level window:

So the problem there definitely isn't MozMill's fault. That being said, spinning the event loop is a nasty thing to do, especially in JS. Can you rework your synchronization code to use callback functions instead?
Created attachment 662074 [details]
minimized testcase

This is a simplified testcase which can be used to reproduce the hang in processNextEvent() with Firefox 16.0 Beta 3.
I have talked with Bobby and Justin on IRC and what I got back is that Mozmill should stop spinning the event loop entirely (as already mentioned in the summary) and make use of callbacks instead. But that means that our test code will NO longer by synchronous and introduces all the complexity as what we know from other test frameworks like Mochitest. While this is probably the necessary way to go it will completely change the test framework.

Such a change is not something we can do in a short term. It also would have to be done wisely. So I will put this up as a roundtable item for next weeks Automation Development meeting.
Whiteboard: [mozmill-2.0?][mozmill-1.5-next?]
(In reply to Bobby Holley (:bholley) from comment #1)
> It's worth keeping in mind that bug 789773 manifests in a zombie state
> because our underlying C++ appshell code actually spins the event loop while
> creating a top-level window:
> cpp#1776

In case of that I will lower the severity of this bug to normal.
Severity: critical → normal
No longer blocks: 790218
Maybe generators would do the trick? I think sticking a couple of |yield| statements into the mozmill tests would be a lot less confusing that callbacks. What do you think, Henrik?
Would you mind to give an example? So far I have never used generators and I can't see right now how it would solve the problem. So I would really appreciate to hear more about your idea.
So, my understand is that mozmill wants to be able to write tests that look procedural even though they're waiting for asynchronous events. So, suppose you have a function like this:

function foo() {

you could instead do:

function foo() {

  yield function(callback) { addListenerForX(callback); }


  yield function(callback) { addListenerForY(callback); }

  // Throws StopIteration

Then, to invoke foo, you do:

var curr = foo;
function doStep() {
  try {
  } catch(e) { allDone(); }

Just a rough sketch - but does that give you an idea? See for more details
That also looks complicated but most of it could somewhat be hidden in the Mozmill API. I haven't had the time yet to check all this.

Beside that I have found the following post about os.file:

They are doing file i/o asynchronously but in the example code it looks like they are synchronizing the code again. But same here, I haven't had time to check that.
Assignee: hskupin → nobody
Would be something we can do together with the move to Marionette in the not yet specified future.
Whiteboard: [mozmill-future]
Sorry for bugspam.

Some weeks ago when I did a little googling about yield,
I found a lot of pages, blogs, wikis.
I would like to share them.

Related to workers:



Related to yield:






Task.js and promises:
-> Promote Promise.jsm from developer tools to toolkit
-->  Experimenting with promises.
--> promise - Addon-SDK

- Implement basic "Task.js" interfaces in Toolkit

- Make the Promise module available to Toolkit consumers


- createPromise() -- use promises with libraries that only support callback arguments
Whiteboard: [mozmill-future] → [mozmill-2.2?]
Mozmill will reach its end of life soon. We are currently working on getting all the tests for Firefox ported to Marionette. For status updates please see bug 1080766.
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Whiteboard: [mozmill-2.2?]
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.