I’m a Juce newbie, so this question may seem naive, but here goes:
As far as I can see, there are no asynchronous file read calls available from the FileInputStream class. There are times when it’s definitely best not to block on a file read. So how do seasoned Jucers handle this? I know from having coded with direct OS-specific file read calls that usually the functions exposed by the OS (e.g. PBRead for OSX…) have an “asynch” parameter that allows you to issue a non-blocking file read <> which is fulfilled sometime later by the OS.
1 Like
Either put the reading in a Thread or ThreadPoolJob, then arrange for a callback when its done.
I tried it out that way and it does work. But doing it that way is wasteful of CPU cycles. There is still a thread somewhere in the JUCE app taking up resources, blocking while that file read completes. If you have true asynch file reads, there is no thread anywhere in the app that has to block waiting for the read to complete. The OS simply calls your callback when it has completed read, and the app is meanwhile free to do everything else.
We really do need true asynch file reads for the very heavy media file I/O!!
I doubt very much that the thread constitutes such a resource overhead. In fact, I doubt very much that you’d notice any such overhead at all. A thread blocked on an event does not take any noticable CPU resource. And how do you suppose that the OS has done this? Async file reads just abstracts away the thread you otherwise has to supply.
