fasterthanlime OP , vor 2 Tagen

oooh, tokio does fun things (like automatically boxing your future if it's big and you're in debug mode)

omni , vor 2 Tagen

@fasterthanlime wow 🥺 thank you tokio

18+ k0nserv , vor 2 Tagen

@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 OP , vor 2 Tagen

@k0nserv I would assume so!

fasterthanlime OP , vor 2 Tagen

I'm learning lldb against my will, send help

dysfun , vor 2 Tagen

@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.

fasterthanlime OP , vor 2 Tagen

@dysfun it's not as bad in my 30s, now that I'm no longer fighting it

fasterthanlime OP , vor 2 Tagen

Ah, I see

fasterthanlime OP , vor 2 Tagen

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 , vor 2 Tagen

@fasterthanlime sorry, not terribly helpful but i never did catch why you were putting async executors into a loadable module?

fasterthanlime OP , vor 2 Tagen

@dysfun the module uses a crate that calls tokio::spawn, tokio::time::Sleep::new, etc.

fasterthanlime OP , vor 2 Tagen

@dysfun but yeah, maybe the solution is to patch all those crates to allow passing in an executor instead...

dysfun , vor 2 Tagen

@fasterthanlime yeah i don't like when things are running their own executors behind my back

fasterthanlime OP , vor 2 Tagen

@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.

cr1901 , vor 2 Tagen

@fasterthanlime

>different monomorphizations = missing symbols

Can you elaborate? Why would you get missing symbols?

(Come to think of it, how do you store Rust monomorphizations in a shared object without it being inlined into a fn without generics?)

kinnison , vor 2 Tagen

@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?)

fasterthanlime OP , vor 2 Tagen

@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.

kinnison , vor 2 Tagen

@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.

tedmielczarek , vor 2 Tagen

@fasterthanlime @kinnison one can read about Swift's implementation of ABI stability for insight into how complex these issues are to solve: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0260-library-evolution.md (I've been really impressed with how the Swift folks have tackled these thorny problems!)

fasterthanlime OP , vor 2 Tagen

OH LORDY LORD I solved it.

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.

mikaeleiman , vor 2 Tagen

@fasterthanlime Ouch! That could have taken a month or two to figure out…

Alonely0 , vor 2 Tagen

@fasterthanlime lordy lord, indeed.

ivan , vor 2 Tagen

@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 , vor 2 Tagen

@fasterthanlime wait, does it work now?

fasterthanlime OP , vor 2 Tagen

@noah with a little help, yeah

a RuntimeFut<F> future, which enters a runtime handle before polling. along with the RuntimeFutExt trait which provides attach, which wraps self in a RuntimeFut

fasterthanlime OP , vor 2 Tagen

@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.

fasterthanlime OP , vor 2 Tagen

@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 , vor 2 Tagen

@fasterthanlime unfortunately that part has no nice solution in rustland

noah , vor einem Tag

@fasterthanlime still the fact that this works at all is amazing

fasterthanlime OP , vor einem Tag

@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

nrab , vor 2 Tagen

@fasterthanlime i want to learn lldb and it can do some neat stuff but every time I’m reminded how inferior it is to gdb and then I stop learning it

PierreLebeaupin , vor 2 Tagen

@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…

whitequark , vor 2 Tagen

@fasterthanlime KITTY EARS