Remove eventsExecutorService thread

[HelgeStenstrom]

I don't think it's needed.
The player runs fine without it. The call() method of StreamPlayerEventLauncher gets called anyway.

See also #49 .

[goxr3plus]

It's needed i specifically wrote that mechanism to deal with multiple threads calling the same player with different events.

I had issues in XR3Player and spend two nights to solve it.

I will tell you a very simple example.

Stop player is fired and half of the procedure happens and just before the player is stopped the pause triggers from another thread and causes a deadlock.

I can be more specific i remember that happening more than 10 times and the player was stack.

[HelgeStenstrom]

Yes, please be more specific.
I'm interested to learn about the scenario where multiple threads are calling the same player. What is the use case?

How would it be helped by having a separate temporary event thread that doesn't run in parallel, but rather instead of the main thread? On

java-stream-player/src/main/java/com/goxr3plus/streamplayer/stream/StreamPlayer.java

Lines 217 to 219 in d32a46a

	return eventsExecutorService
	.submit(new StreamPlayerEventLauncher(this, status, encodedStreamPosition, description, listeners))
	.get();

you are creating a task, start it on the executor, and wait for it complete, rather than just starting it and then do other things in parallel.

[goxr3plus]

It's because the upcoming events must run in row instead of one interrupting the other.

The guys from xTremepamedia player which i have send you before have also noticed that and used the exact same solution on their class.

Imagine we had the same idea even for await method :).

I implemented it through trial and error.

[HelgeStenstrom]

I don’t think it looks like the same solution. Compare their play method to yours. They have most of it guarded by a thread lock, you have not. (I’m browsing the code on my mobile phone, so I might be wrong).

Your generateEvent method creates a temporary thread or task on an existing thread, I’m not sure which. They don’t.

[HelgeStenstrom]

I need to correct myself. Their notifyEvent really does create a thread. But they don’t wait for its termination or for it to return a result. I don’t understand their solution either.