pulse-binding-rust
pulse-binding-rust copied to clipboard
jnqnfe
Possible tokio integration?
With the Futures and Async/Await features soon to be stabilized, is it possible to use this library asynchronously with Tokio? If so, could documentation and possibly a feature be added that allows for it so that actions to be taken after a sound is played can be done through future combinators? I haven't really dug into the library, but it didn't give us compilation issues, so we went with it for a hackathon. We'd like to integrate it into our production application, but we use a Tokio based framework and having this work with that natively would be really useful.
Yeah I've been waiting for things to stabilise for a while now, and the plan is to definitely move things over to it once they have. This question was raised a while ago (the issue seems to have vanished) and at that time the futures/tokio guys were in alpha development of a v2/3 and i was waiting for that to stabilise, but things seemed to stall with stuff being merged into the core language instead.
I don't have plans currently to link up to the existing futures/tokio/romio stuff, partly because I'm not using the nightly compiler, only the stable version available in my Linux distro, partly also due to being rather busy currently and not wanting to potentially waste effort on potentially outdated crates.
I am not certain how difficult it might be to link up the existing closure based callbacks and tokio now, the delay waiting for things to stabilise and not using a nightly compiler (only the stable one available in my Linux distro) meant that I have yet to end up exploring use of this stuff.
I don't know if this would be useful at all for you but I have started wrapping parts this library with futures/streams for my personal use.
https://github.com/Pajn/libpulse-futures
Now that async/await is stable it would be very cool to see this crate utilize Futures.
I'm willing to help if this is something that there is interest in
@MaxVerevkin Unfortunately not really, no, sorry. I started looking into it a while ago but did not get very far and have not had time yet to try again. While on the face of it it's not a big deal to transform the API functions to return futures, there are complications and difficulties in figuring out how to wire up everything behind the scenes to work correctly, which is the problem.
From what I recall, one relatively small complication I was struggling with was figuring out how the cancellation mechanism of Operation objects could possibly be wired up such that dropping a future involving one would correctly cancel execution of the callback. I also very vaguely remember some requirement I found in the documentation of core or tokio regarding consistency or inconsistency of some important component of managing tasks I think it was, and I could not understand how on earth to deal with that requirement, and I can't remember now what on earth it even was. :/
The biggest thing I don't recall ever getting my head around fully was figuring out what was necessary to actually marry the futures with the mainloops, such that the C callback events fired by the mainloop would trigger updates of those futures, which I guess may involve creating custom executor or something. As you can tell, I really need a refresh on all of this stuff, and possibly some guidance in order to figure it out.