java-stream-player icon indicating copy to clipboard operation
java-stream-player copied to clipboard

Remove eventsExecutorService thread

Open HelgeStenstrom opened this issue 5 years ago • 5 comments

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

See also #49 .

HelgeStenstrom avatar Sep 24 '19 21:09 HelgeStenstrom

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.

goxr3plus avatar Sep 24 '19 22:09 goxr3plus

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 https://github.com/goxr3plus/java-stream-player/blob/d32a46a1f7d105a2c5350ae5bd04fdc1edd47baa/src/main/java/com/goxr3plus/streamplayer/stream/StreamPlayer.java#L217-L219 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.

HelgeStenstrom avatar Sep 25 '19 05:09 HelgeStenstrom

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.

goxr3plus avatar Sep 25 '19 06:09 goxr3plus

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 avatar Sep 25 '19 10:09 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.

HelgeStenstrom avatar Sep 25 '19 10:09 HelgeStenstrom