Skip to content

Conversation

@tlively
Copy link
Member

@tlively tlively commented Mar 23, 2022

This ensures that the refcounts are correctly decremented even if a proxied task
throws an exception, although it won't protect again other bad things like
dropped work that could happen in that case.

This ensures that the refcounts are correctly decremented even if a proxied task
throws an exception, although it won't protect again other bad things like
dropped work that could happen in that case.
@tlively tlively requested a review from sbc100 March 23, 2022 16:49
@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

@sbc100 is there a way to extract this common code out into a helper function that will be available both inside library_pthread.js and worker.js?

@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

Aha, it turned out to be straightforward.

// Always decrement the ref count.
Atomics.sub(HEAP32, e.data.queue >> 2, 1);
}
executeNotifiedProxyingQueue(e.data.queue);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can call library functions directly from worker.js can you? I think you would need to make sure the library function was exported on the module and then call Module[' executeNotifiedProxyingQueue']. Ensure its exported and not minimized is kind of tricky... and happens in couple of different places I think (for example MINIMAL_RUNTIME has explicit code to export these on the Module).

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % the usage in worker.js

@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

Somehow the call to the library function in worker.js succeeds. I verified this by changing its name at the worker.js call site, which caused the tests to fail due to the unknown name. Optimizations don't seem to cause problems either, since all the tests pass.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 23, 2022

Somehow the call to the library function in worker.js succeeds. I verified this by changing its name at the worker.js call site, which caused the tests to fail due to the unknown name. Optimizations don't seem to cause problems either, since all the tests pass.

The way that the module is injected into the workers namespace is still kind of mystery to me.. and I think the behaviour is different in the browser to in node. So maybe check that test passes when run as a browser test (I know its kind of pain, but I think it should be easy enough use self.btest_exit to run the same test in test_browser.py.

@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

I think the behaviour is different in the browser to in node

This is alarming!

@sbc100
Copy link
Collaborator

sbc100 commented Mar 23, 2022

I think the behaviour is different in the browser to in node

This is alarming!

Yes, I think it stems from the fact that the worker model is different and this effects the way that code gets imported.

Luckily it only effects rather small amount of code in worker.js.. most code is not effected.

If you are correct and we don't need to specify Module['stringName'] when we call back into module code from the worker, then we can probably update a lot of the code there.

@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

Unfortunately I won't be able to run the browser test until I'm back in the office on April 11 and have access to a desktop development environment again :/

@sbc100
Copy link
Collaborator

sbc100 commented Mar 23, 2022

I can verify this for you.. (you can also use ssh port forwarding if you can ssh into your desktop)

@tlively
Copy link
Member Author

tlively commented Mar 23, 2022

Thanks, that would be great. Unfortunately I don't think ssh port forwarding for graphics works with the ChromeOS SSH app :( I could probably CRD into my workstation, but IIRC it's not set up correctly for that.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 23, 2022

Thanks, that would be great. Unfortunately I don't think ssh port forwarding for graphics works with the ChromeOS SSH app :( I could probably CRD into my workstation, but IIRC it's not set up correctly for that.

No, I meant port-forward the http server port. For example using emrun and port forward local port 6931 to your desktop port 6931... then browse to http://localhost:6931/.

Here is what I sometimes do:

$ ./tests/runner browser.test_foo --save-dir --browser=0
$ ./emrun --no_browser /tmp/emscripten_test/

This will compile the browser test but not try to run it.. then you can browse to port 6931 to run the test in your own tab.

@tlively
Copy link
Member Author

tlively commented Apr 8, 2022

I'm back in the office so I was able to run the browser test directly on my workstation. It worked fine! I'll go ahead and land this.

@tlively tlively merged commit 765ce7f into main Apr 8, 2022
@tlively tlively deleted the proxying-finally-refcount branch April 8, 2022 22:09
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

Successfully merging this pull request may close these issues.

3 participants