@fasterthanlime Why does it stack overflow in debug mode, but not release? Is it just that the futures the compiler generates are much larger in debug?
@fasterthanlime gotta say i was fairly impressed when i had to do this a couple of years ago. it's not ideal, but it's about as much as you can hope for.
but i was also debugging inline assembly, so maybe my expectations were lowered.
I'm at a loss re: how to make tokio happy across shared object boundaries. Yes there's N copies of tokio's code, now I can't share them because different monomorphizations = missing symbols (the cargo-add-dynamic trick doesn't work with my "cdylib plugins" approach).
Handle::enter across SOs panics. Handle::spawn panics. I thought "mostly" tokio::spawn needed a "current runtime", but "Sleep::new" does too, duh.
I foresee lots of debugging in my future.. god that's a lot of debugging.
@dysfun me neither but that would be fine — hickory-resolver has a "Sync" interface which is #[tokio::main] in a trench coat and that works great! It's getting it to use the tokio executor I already have which is a hassle.
@fasterthanlime It's a long-shot but would something akin to the rustc shared object work (ie. put tokio et al. into an SO which you link from both your app and your plugin?)
@kinnison that doesn't work (it's the monomorphization thing): both my app and my plug-in invoke tokio functions with different generic types (often, async blocks which are opaque types) — if you use the libtokio.so from the app with the lib, it has missing symbols. if you use the other, same.
@fasterthanlime Aah bugger :( I admit I've never been brave enough to try and do rust-plugins-to-rust-apps so I'm very interested in your experience. Good luck.
The outer and inner "tokio"s had different cfgs, so the layout of tokio::runtime::Handle were different, hence, mutex::lock was falling on some other fields, oh god.
@fasterthanlime on one hand, cargo features are a petard we can use to hoist ourselves, on the other hand they let people get their work done on time, so impossible to say if they are bad or not
@noah I mean it's not ideal. very easy to accidentally use the wrong thread-local (but tokio::spawn, Sleep::new, etc. will yell at you that there's no reactor running)
..and the whole tokio code is duplicated in all shared objects but... I actually do not mind in this case, since no code changes required = happy me.
@noah more importantly, SUPER easy to accidentally enable a different set of tokio features and land on different internal layouts, which uhhh isn't great
@noah yeah! I'm very VERY happy with it — this new structure makes build times & deploy times ridiculously fast for me: I can have a new version of my site up and running around the world in ~2 minutes
@fasterthanlime has it gained support for variants in Dwarf, which is what Rust justifiably uses to provide debug info for enums? Last time I tried this was such a huge hole in my ability to debug Rust that I ended up installing FSF GDB, complete with manual signing step because debuggers need to be code signed these days…