00:50 <noracodes> spacekookie: you mentioned that you have a problem accessing "something that itself has to await (to lock a mutex)" - my goto would be to use try_lock() in the poll_fn closure and just exit with pending if the mutex is locked

01:13 <spacekookie> noracodes: oh I solved that, the code isn't uploaded yet though

01:47 <spacekookie> noracodes: there: https://git.open-communication.net/qaul/qaul.net/blob/async/netmod-wd/src/lib.rs#L70

01:47 <spacekookie> The biggest problem I had was that the mutex.lock() future didn't implement pin/unpin

01:47 <spacekookie> Thus the required unsafe

02:01 <noracodes> related, spacekookie: https://www.youtube.com/watch?v=shtfSMTwKRw

02:01 <noracodes> a very useful discussion of that API

02:02 <spacekookie> Oh sweet! I knew they were gonna do a stream. I guess I'll look at that tomorrow

02:02 <spacekookie> Gonna sleep in a bit. CHeck out the stuff I queried you

02:02 <spacekookie> Night y'all!

02:02 <noracodes> will do. Good night!

15:30 <jess3jane> noracodes spacekookie: futures has a future aware mutex btw if the "wait for lock" comes up again

15:47 <spacekookie> jess3jane: I was using the async-std mutex

15:54 <jess3jane> ah

16:43 <spacekookie> jess3jane: I'm wondering if you have a good pattern on how to poll lot's of things in a loop, without having to worry about one of the poll's not returning anything blocking you from polling the rest

16:44 <spacekookie> I guess I don't actually want to do this in a loop, so instead just poll each endpoint individually?

16:44 <jess3jane> uhhhh i don't think there's a way if it blocks when it polls it blocks when it polls

16:45 <spacekookie> Hmm

16:45 <spacekookie> I guess maybe I could just spawn a task for each endpoint then. Because it's not like there's the overhead of a stack for each of them

16:45 <spacekookie> And if one has no inputs, it won't get woken anyway

22:21 <amanjeev> omg i just sent myself a patch via git send-email and i am so happy! going to try with --cover-letter --annotate after dinner