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

Expose a way to implement a backoff protocol, refactor errors and other minor improvements #176

Merged
merged 7 commits into from Dec 28, 2018

Conversation

Projects
None yet
3 participants
@ferjm
Copy link
Member

ferjm commented Dec 21, 2018

This PR exposes the EnoughData and NeedData Player events that allow consumers to implement a backoff protocol.

I made a couple of significant refactors:

  • I moved the list of Player observers and renderers out of PlayerInner to avoid deadlocks. For more information, you can read this IRC conversation.
  • I had to change the way we report errors in general to allow external consumption.
@ferjm

This comment has been minimized.

Copy link
Member

ferjm commented Dec 21, 2018

@ceyusa

This comment has been minimized.

Copy link
Contributor

ceyusa commented Dec 21, 2018

what worries me about this change is that we are exposing a gstreamer specific behavior, when the interface is supposed to be generic.

@ferjm

This comment has been minimized.

Copy link
Member

ferjm commented Dec 21, 2018

Well, despite the event name choice, I don't think this is a Gstreamer specific behavior. What we are exposing is a way for the Player to control the flow of data that it receives. I expect other backends to have equivalent needs, and if they don't, we can still just signal the need of data.

Anyway, I am open to suggestions about how to implement a backoff protocol in a different way :)

pub struct GStreamerPlayer {
inner: RefCell<Option<Arc<Mutex<PlayerInner>>>>,
observers: Arc<Mutex<PlayerEventObserverList>>,
renderers: Arc<Mutex<FrameRendererList>>,

This comment has been minimized.

@Manishearth

Manishearth Dec 28, 2018

Member

do both the lists and the individual renderers need to be behind Arcs and mutexes? I feel like having Vec inside the list may be fine here?

This comment has been minimized.

@ferjm

ferjm Dec 28, 2018

Member

Each individual renderer is accessed from the layout and gstreamer threads, so I think we need to have them behind Arcs and mutexes.

This comment has been minimized.

@Manishearth

Manishearth Dec 28, 2018

Member

ah, okay then. r=me

@ferjm ferjm merged commit 88a8594 into servo:master Dec 28, 2018

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

@ferjm ferjm deleted the ferjm:player.src.max_buffer branch Dec 28, 2018

@ferjm ferjm referenced this pull request Jan 9, 2019

Merged

Use a Once per Player init #177

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment