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

singletons that are retroactively turned into EventEmitters should ca… #10995

Merged
merged 1 commit into from Nov 3, 2017

Conversation

Projects
None yet
4 participants
@ckerr
Member

ckerr commented Nov 2, 2017

This follows up on a discussion that @mgc, @MarshallOfSound, and I had this week tracking down the root of the AutoUpdater error case crash.

First try

At the end of that debugging session we'd decided to defer the singletons' instantiation until after Object.setPrototypeOf(AutoUpdater.prototype, EventEmitter.prototype) was called so that the newly-created AutoUpdater would have its EventEmitter parent fields initialized.

Unfortunately that's not going to work. Calling new AutoUpdater() in JS doesn't actually create a C++ AutoUpdater object because AutoUpdater and the other singletons don't insert a constructor into the JS bindings: (a) it's unnecessary binding code to (b) give clients the ability to create multiple instances of things designed to be singletons. So, while we could add constructor bindings to make this possible, it opens up more potential problems.

Second try

EventEmitter() defers its initialization to an init() helper function, and Samuel suggested that would work as well. I'm going to chalk this up to my inexperience with JS but I wasn't able to get autoUpdater.init() to work (and it is defined a little differently from other members, ie EventEmitter.init = function(){...} vs. EventEmitter.prototype.setMaxLixteners = function(){...}) but IMO this is just as well because the approach I used is cleaner & should work even if Node changes EventEmitter's internals.

Third try

So after much prologue (and more digging and learning how native_mate works), we actually wind up with a pretty small & simple patch. after reparenting the singletons' prototypes, we call the parent's constructor...

@ckerr ckerr requested review from mgc and MarshallOfSound Nov 2, 2017

@ckerr ckerr requested review from electron/reviewers as code owners Nov 2, 2017

@welcome

This comment has been minimized.

Show comment
Hide comment
@welcome

welcome bot Nov 2, 2017

💖 Thanks for opening this pull request! 💖

Here is a list of things that will help get it across the finish line:

  • Follow the JavaScript, C++, and Python coding style.
  • Run npm run lint locally to catch formatting errors earlier.
  • Document any user-facing changes you've made following the documentation styleguide.
  • Include tests when adding/changing behavior.
  • Include screenshots and animated GIFs whenever possible.
    We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

welcome bot commented Nov 2, 2017

💖 Thanks for opening this pull request! 💖

Here is a list of things that will help get it across the finish line:

  • Follow the JavaScript, C++, and Python coding style.
  • Run npm run lint locally to catch formatting errors earlier.
  • Document any user-facing changes you've made following the documentation styleguide.
  • Include tests when adding/changing behavior.
  • Include screenshots and animated GIFs whenever possible.
    We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.
@codebytere

Does this cover all the modules that are EventEmitters?

@ckerr

This comment has been minimized.

Show comment
Hide comment
@ckerr

ckerr Nov 2, 2017

Member

Not all the EventEmitters -- just those that have singletons instantiated on the C++ side and passed along the bridge.

EventEmitter subclasses that are designed to be instantiated on the JS side with new Subclass() don't have this problem, so they don't need this explicit workaround

Member

ckerr commented Nov 2, 2017

Not all the EventEmitters -- just those that have singletons instantiated on the C++ side and passed along the bridge.

EventEmitter subclasses that are designed to be instantiated on the JS side with new Subclass() don't have this problem, so they don't need this explicit workaround

@codebytere codebytere merged commit 41fa61b into master Nov 3, 2017

9 checks passed

ci/circleci: electron-linux-arm Your tests passed on CircleCI!
Details
ci/circleci: electron-linux-arm64 Your tests passed on CircleCI!
Details
ci/circleci: electron-linux-ia32 Your tests passed on CircleCI!
Details
ci/circleci: electron-linux-x64 Your tests passed on CircleCI!
Details
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
electron-mas-x64 Build #5639 succeeded in 17 min
Details
electron-osx-x64 Build #5614 succeeded in 17 min
Details
@welcome

This comment has been minimized.

Show comment
Hide comment
@welcome

welcome bot Nov 3, 2017

Congrats on merging your first pull request! 🎉🎉🎉

welcome bot commented Nov 3, 2017

Congrats on merging your first pull request! 🎉🎉🎉

@codebytere codebytere deleted the initialize-retroactive-event-emitters branch Nov 3, 2017

@jkleinsc

This comment has been minimized.

Show comment
Hide comment
@jkleinsc

jkleinsc Nov 6, 2017

Contributor

Fixes #10433

Contributor

jkleinsc commented Nov 6, 2017

Fixes #10433

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment