Question regarding trait bounds for some closures in gstreamer-rs

[Sebastian Dröge]

On Sun, 2022-02-20 at 05:14 -0700, Steven Fontaine via gstreamer-devel wrote:
> 
> If I understand your suggestion correctly, you're saying that the
> Arc+Mutex shouldn't be required, and I can simply clone the event
> loop proxy (which is replaceable with an mpsc channel for this
> example) and send that into the first closure, then inside that
> closure, clone it again and send it into the appsink closure.
> However, this is exactly what I was trying before moving to the
> Arc+Mutex approach, as attempting to move the cloned event loop (or
> mpsc sender) into only the decodebin closure causes rust to complain
> about the event loop not being Sync. 
> [...]
> Am I misunderstanding your suggestion?

No, I was confused, sorry. Of course you can't clone the sender from
the callback because cloning would also require the sender to be Sync.

Specifically the mpsc sender from std will change its "mode" depending
on how many senders there are and other conditions, so it's not just
refcounting after all.

Either you'll have to use a different channel that fulfils these
constraints or you indeed need the mutex/arc combination.

> Regarding crossbeam, the Sender which rustc is referring to here
> lives within a glutin::event_loop::EventLoop, so a crossbeam channel
> wouldn't be a drop-in replacement. It would be fairly trivial to make
> it work, but I'd like to avoid additional dependencies if I can. That
> said, if a crossbeam channel ends up being the most efficient option,
> that's certainly what I'll go with.

That's going to be the more efficient solution if you can change the
channel used by glutin, yes.

It probably doesn't matter either way though. No matter which of the
options you use, it will likely make no measurable difference in
performance for this use-case :)

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com