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
ARGVMI~1.PIFIsn't that pretty much how non-blocking IO works? The syscall returns immediately if the bytes are already in memory, otherwise EAGAIN and wait for a notification via epoll.
But it doesn't work for files, for some reason…
@argv_minus_one @dysfun @natty Well, yes and no. There's no particular reason to go to the effort of spinning up a new software thread for each I/O task. Take a look at Linux's io_uring API, it demonstrates how async IO can be made extremely lightweight, even with a huge number of tasks in-flight.