Joshua BarrettoI made project-wide search in my text editor asynchronous so results stream in from worker threads without blocking the main thread. However, searching is so fast that it finishes before the next frame renders, even on the largest project I work on, so it was entirely wasted effort.
princess pancake 
@jsbarretto it's not really a waste when the async I/O is likely the reason the frame was rendered on time
@natty The I/O isn't itself meaningly faster (workers still block on file access, so it's only asynchronous from the perspective of the main threads). But I was hoping to see the number of results tick up in a more satisfying way instead of appearing instantly. I realise that this is a silly thing to be sad about though
gaytabase
@jsbarretto @natty a bit relevant to me this week as i build a new foundation for async i/o.
in C.
@jsbarretto @natty (nightmare of course is not even cross platform, it's the bit where i don't have any cool facilities and have to using blocking i/o and a threadpool)
@jsbarretto @natty huh? i mean when there are no async file i/o apis. so the most obvious thing you could call 'in flight' is literally one op per OS thread.
@jsbarretto @natty oh, i haven't decided what to do yet. like your example, is it worth spinning up a new thread for what could be a small op?
OTOH, if we don't do that, we have to have elaborate thread management
@jsbarretto @natty i know. but actually i think it's funnier that tokio starts tens of threads of my machine even if i do no i/o than that it does this.
also the docs said something about a 1000 thread default limit so shrug
@jsbarretto @natty i've no idea. i am allergic to tokio and its build times so i try not to keep up with them.
ARGVMI~1.PIF