@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

@jsbarretto @natty do a tokio

@dysfun @natty Ah yes, the "I hope spawning a thread is cheaper than reading this tiny text file from the fs cache" gamble

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

@dysfun @natty Hmm, is a thread pool useful in that context? If you're heavily I/O-bound then you'll just want to spin up more soft threads than hardware threads to have many operations in-flight. If not I/O-bound, then context switch overhead might be quite high

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

@dysfun @natty Yes: but you'll want to be spinning up lots of threads instead of just using a fixed pool (unless I'm misunderstanding the operation of your pool and it just grows when under pressure).