How to ensure event is fired only Once! about haxe-concurrent HOT 8 CLOSED

I am not familar with the EventEmitter API. Can you provide a minimal self-containing runnable test class?

from haxe-concurrent.

Hi @sebthom this is a reproducible class, it works for small test

import buddy.Buddy;

using buddy.Should;
/**
	@author Damilare Akinlaja
**/
class Main implements Buddy<[TestEvent]> {}

class TestEvent extends buddy.BuddySuite {
	public function new() {
		describe("Event emitter test", {
			it("should emit only once", (done) -> {
				final eventEmitter = new EventEmitter();
				eventEmitter.once('start', (values) -> {
					final start = values[0];
					final end = values[1];
					start.should.be(1);
					end.should.be(100);
					done();
				});
				eventEmitter.emit('start', 1, 100);
				eventEmitter.emit('start', 2, 100);
			});
		});
	}
}

But when I use it on a more bigger project and send many events, there is an obvious delay before listeners are triggered.

It fails entirely on C++ target with timeout errors Timeout after 5000 ms in a more complex project with many events.

from haxe-concurrent.

Hi, the test works fine for me in CPP. But it fails for javascript. The reason seems to be your usage of the rest operator.

Testing with Javascript I get this error:

Event emitter test
  should emit only once (FAILED)
    Expected 100, was null

I guess the reason is your usage of the rest operator with the EventDispatcher#fire method which only declares on argument.
In Javascript if you pass more arguments to a function than it declares, the remaining arguments are silently dropped by the JS runtime. Interestingly tho, it works on all targets except JavaScript, so maybe this is a bug in Haxe's JS transpiler in the context of generics, the haxe.Rest type and the rest operator.

from haxe-concurrent.

@sebthom noted! I'll fix that for JavaScript.

I still wonder why I get timeout errors in C++ in my project.

from haxe-concurrent.

Without having looked into your project. Maybe your are running into race conditions because of multi-threading. I don't think the way you are accessing the maps in the EventEmitter is thread-safe.

from haxe-concurrent.

@sebthom any idea how I can solve this problem?

from haxe-concurrent.

@sebthom any idea how I can solve this problem?

You could try to guard all calls to a map with a dedicated hx.concurrent.RLock instance.

from haxe-concurrent.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

from haxe-concurrent.