Migrating an existing sync crate to async

[alsuren]

Brief summary

Reasons for needing to do this include:

• Due to the "coloured functions" problem, it is quite common to be coerced into turning a blocking library into an async library.
• Sometimes, converting to async is done for performance reasons.

I know of multiple examples of projects that have done this in the recent-ish past. I will write them down in the "characters" section, and if anyone wants me to add links to issues/pull-requests or @mention the relevant parties to give more insights then I will.

I probably don't have the brain-space to write this up properly myself, but it came up in one of the writing sessions that I attended, and I put something on my todo list to make a ticket about it, so this is my attempt at clearing my backlog.

It is also mentioned in #98, to that issue description should be updated now that this ticket exits. 😀

Optional details

• (Optional) Which character(s) would be the best fit and why?
  • Alan: the experienced "GC'd language" developer, new to Rust
    • Goose started of as a sync http load testing api and I helped them get started with their async port (they initially wanted to provide both sync and async interfaces from the same codebase, but I convinced them that this might be impossible).
  • Grace: the systems programming expert, new to Rust
    • My housemate has recently ported btleplug cross-platform bluetooth library from a mishmash of blocking/callback-based to async fn. (He is also co-maintainer with me on mijia-homie/homie-influx/bluez-async and a bunch of other crates though, so I guess you could consider him to be a Barbara by now)
  • Niklaus: new programmer from an unconventional background
  • Barbara: the experienced Rust developer
• (Optional) Which project(s) would be the best fit and why?
  • MonsterMesh could use btleplug as the gateway/debugging interface?
    • mijia-homie could reasonably have been written in the blocking style at the start (maybe it was, and I am forgetting something?).
      • blurz (the bluetooth library that we were using previously) was written in the blocking style, and connect() would block for up to 30 seconds.
      • blurz was also !Sync because of how it integrated with dbus, so we ended up with data outages of up to 30 seconds on all sensors whenever we attempted to connect.
      • I describe this problem in the concurrency section of my slides at https://alsuren.github.io/mijia-homie/docs/presentation
  • DistriData could reasonably have been written in the blocking style and then ported to tokio to use some functionality stolen from linkerd or something? (TrafficMonitor is more likely to have been written in the async style from the start, so less appropriate)
• (Optional) What are the key points or morals to emphasize?
  • Lifetimes are hard. Wrapping everything in Arc helps a lot, as soon as you get over your squeamishness about perceived performance.

[pickfire]

What about async back to sync? Is it possible?

[ar37-rs]

What about async back to sync? Is it possible?

if you only need simple fetching request, you can mix them: https://github.com/Ar37-rs/asynchron/blob/main/example/fltk_fetch/src/main.rs

[pickfire]

@ar37-rs I think you mistake what I was mentioning. I was talking about that with regard to migrating existing sync crate to async. Although some crate may start by creating an async crate, but if someone wants a sync API, is there a low effort way of doing so?

Yes, one could use block_on but it would be simpler with reqwest::blocking. This could overlap with #54 but sometimes the author already know blocking is alright but some crates such as surf are designed with async in the first place, so the only method for it is block_on, so is there a simpler way to get a sync API?

[ar37-rs]

@ar37-rs I think you mistake what I was mentioning. I was talking about that with regard to migrating existing sync crate to async. Although some crate may start by creating an async crate, but if someone wants a sync API, is there a low effort way of doing so?

Yes, one could use block_on but it would be simpler with reqwest::blocking. This could overlap with #54 but sometimes the author already know blocking is alright but some crates such as surf are designed with async in the first place, so the only method for it is block_on, so is there a simpler way to get a sync API?

oops sorry, i misunderstood your question. i'm niklaus friend's who currently learning how to sync/asynchronize multi-threaded stuff i don't have concrete answer on that, i just agree that the future is shiny.