Tokio/futures async support

[rubdos]

As suggested in #32:

I've been experimenting with porting dbus-tokio to futures 0.2.0, and it seems like its dependency on tokio will get a lot lighter (seems like only tokio-reactor will be needed). I suggest that whenever tokio releases their futures 0.2 support, we start implementing this. For now, we can discuss a bit how the interface should look like.

One of the things I think would be extremely cool, would be the possibility to "subscribe" to new players coming online. With the current interface, you basically have to query dbus on set intervals for active players. Having something like PlayerFinder::stream() -> impl Stream<StreamItem=Player> would be very cool.

Secondly, having a Player somehow emit events in form of a Stream would be very useful too.

[Mange]

I really like the idea of streaming players.

I also like the plan to wait for 0.2. I'm excited!

[rubdos]

I also like the plan to wait for 0.2. I'm excited!

Cool. I'll probably catch the guys at dbus-rs somewhere next week, give them the port for 0.2 I was working on.

[rubdos]

FYI, I've dropped my (non working) futures 0.2 code over at dbus-rs diwic/dbus-rs#129

[Mange]

FYI 0.2 just shipped, but it seems like it's only meant for experimentation still.

I consider 0.2 a "snapshot" that's good for experimentation but shouldn't be used heavily, since stable 0.3 should be coming in a couple of months or less.

[rubdos]

FYI 0.2 just shipped, but it seems like it's only meant for experimentation still.

Yeh, I read that too. Thing is, we have to await! Tokio first, because their support is still quite alpha-ish :-)

[ischeinkman]

Would it make more sense to use tokio + dbus's nonblocking support, or to just roll a custom version via callbacks? The second would likely be much easier since it would reuse most of the existing code and also be executor-independent.

[Mange]

I honestly don't know. I'm not well versed in these ecosystems yet.

[rubdos]

or to just roll a custom version via callbacks? The second would likely be much easier since it would reuse most of the existing code and also be executor-independent.

That would not at all integrate in any ecosystem. Callbacks could be useful, but are not an alternative to async-await integration.

[ischeinkman]

Oh I meant using custom futures implemented via having callbacks update a response value and then waking the waiting future.
I've actually started implementing one based mostly on dbus::nonblock, but there were still some places I needed to do the custom future approach -- the biggest being the fact that there is currently no send_with_reply_async available, so I had to roll my own.

[rubdos]

Oh I meant using custom futures implemented via having callbacks update a response value and then waking the waiting future.

Can't you use channels for that?

I've actually started implementing one based mostly on dbus::nonblock, but there were still some places I needed to do the custom future approach -- the biggest being the fact that there is currently no send_with_reply_async available, so I had to roll my own.

I wonder what dbus-tokio does then, can't you base of that? I just might not have enough knowledge of the internals of tokio et al. though.

[th1j5]

Hey, how is this issue going? Tokio is now version 1.2.0, so maybe it is stable enough to have a look at it again?

I'm asking this because:
I'm using mpris::PlayerEvents to count how many tracks have been played by matching on Event::TrackChanged(_). In the meantime, I'd also like to control the sound etc., but because PlayerEvents is a blocking iterator, the whole (OS-)thread is blocked, and I think it is a bit expensive to need a whole thread just for counting tracks...

I'm probably not qualified to help with this work, quite new to Rust... :/

(Thank you for the library, it's just what I need! I first thought I had to interact with C calls to control Rhythmbox *shiver*, then I discovered D-BUS and now this)

[Mange]

Booting up a thread that just blocks is not very expensive at all afaik, it's how everyone did it before we got async io after all.

It might be time to look into it now, but then again it's very hard to support both async and sync io in the same codebase in Rust from what I can tell. Async tends to take over everything and infecting stuff. Async also adds a huge amount of overhead (a whole runtime) and I've heard that the dbus infrastructure works badly with async io because of assumptions (like with OpenGL and multi-threading), but that could be a big misunderstanding from my part.

If anyone can come up with a design that allows compile-time toggle of async support (I don't mind if it's default or not), that also allows you to plug in different runtimes (tokio, async-std, etc.), then I would be happy to get it in right now!

[th1j5]

Ok, then I'll just use something like std::thread::spawn. Not that it matters very badly...

I do know that some crates use options in their Cargo.toml to mark what you want to use. (e.g. clap = {version = "~2.33.3", features = ["yaml"]} or tokio = { version = "1", features = ["full"] })
So I could imagine a mpris = {version = "2", features = ["async"]}

But I probably can't help further