Skip to content
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

Initialization race condition. #1

Closed
nrn opened this issue Dec 29, 2014 · 8 comments
Closed

Initialization race condition. #1

nrn opened this issue Dec 29, 2014 · 8 comments

Comments

@nrn
Copy link

nrn commented Dec 29, 2014

Given modules a

var i = require('sparkles')()
var b = require('./b')

i.on('foo', function () { console.log('a') })

i.emit('foo', 'a')

and b:

var i = require('sparkles')()

i.on('foo', function () { console.log('b') })

You end up with references to two different event emitters, and only 'a' gets logged. If in a you add your listener before requiring b, they are the same event emitter and work as expected.

@phated
Copy link
Member

phated commented Dec 30, 2014

Do you see this as a documentation issue? The way I expect sparkles to be used is like so:

var sparkles = require('sparkles');
var b = require('./b');

var i = sparkles('my-namespace');

i.on('foo', fn);

i.emit('foo', 'a');

@nrn
Copy link
Author

nrn commented Dec 30, 2014

Clear docs would help, but I think the require and initialize on one line is pretty common for this sort of thing. Can a namespace's ee be added to the global store the first time it is created?

@phated
Copy link
Member

phated commented Dec 30, 2014

I was trying to keep the global cleaned up when all listeners are removed but I could leave the namespace around if I am going to implement #2

@nrn
Copy link
Author

nrn commented Dec 30, 2014

That's a good idea, but I think it would lead to unexpected behavior. Things like a global broadcast channel, where one module periodically issues events through the entire lifecycle of the app, but other modules add and remove listeners asynchronously. It would be hard to tell when all of a sudden you get a new event emitter that isn't receiving the events the original module is broadcasting, just because someone happened to remove the last listener.

Maybe add a require('sparkles').remove('namespace') that nulls out the global reference in case someone wants to clean up after themselves? A little less automagical, but easier to understand.

@phated
Copy link
Member

phated commented Dec 30, 2014

That's a good idea. I basically added that into glogg and it would be nice to be exposed through sparkles instead.

@nrn
Copy link
Author

nrn commented Dec 30, 2014

Ahh, nice. You could put it on the ee itself, and remove all listeners then null out the global reference. I like it.

@phated phated closed this as completed in 834e409 Dec 30, 2014
@phated
Copy link
Member

phated commented Dec 30, 2014

Thoughts on 834e409 ? does it solve this?

@nrn
Copy link
Author

nrn commented Dec 30, 2014

Looks great, solves all my concerns.

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

No branches or pull requests

2 participants