From what I understand, there is a StreamPlayerEventLauncher task which holds information about source, player position, a list of listeners and some other stuff.
The task is submitted to eventsExecutorService.submit(task) and returns a Future.
Then .get() is called on this object. get() blocks until the task is done, i.e., until all listeners have been notified by the call() method of the StreamPlayerEventLauncher.
Since get() is blocking, I wonder why this has to be in a separate thread. What is the lifetime of the thread? It seems to be extremely short, or am I wrong?
Wouldn't the behavior be the same with a simple
new StreamPlayerEventLauncher(this, status, encodedStreamPosition, description, listeners).call();
Can you please explain a bit how this works:
https://github.com/goxr3plus/java-stream-player/blob/d32a46a1f7d105a2c5350ae5bd04fdc1edd47baa/src/main/java/com/goxr3plus/streamplayer/stream/StreamPlayer.java#L206-L224
From what I understand, there is a StreamPlayerEventLauncher task which holds information about source, player position, a list of listeners and some other stuff.
The task is submitted to eventsExecutorService.submit(task) and returns a Future.
Then .get() is called on this object. get() blocks until the task is done, i.e., until all listeners have been notified by the call() method of the StreamPlayerEventLauncher.
Since get() is blocking, I wonder why this has to be in a separate thread. What is the lifetime of the thread? It seems to be extremely short, or am I wrong?
Wouldn't the behavior be the same with a simple new StreamPlayerEventLauncher(this, status, encodedStreamPosition, description, listeners).call();
and no eventsExecutorService at all?