[physfs] 2.0 wishlist...

[Tree]

> Brian Hook wrote:
>>>Full-on async-I/O is probably overkill/overengineering for physfs's
>>>remit (not that it wouldn't be nice!), but non-blocking I/O would
>>>be an adequate basis for some nice things like speculative pulling-
>>>in of level and texture data without causing unavoidable troughs in
>>>the frame rate.
>>
>> Can't the application handle this by spawning a separate thread instead 
>> of relying on presumably platform-specific non-blocking IO routines?
>
> Threading is hell (not to mention that some plats don't have
> usable threads).  Nonblocking IO doesn't involve using platform-
> specific IO routines; regular O_NONBLOCK/O_NDELAY are pretty old
> and well-handled flags working in accord with open()/read()/etc.
>

Well Windows tends to use their own Overlapped IO stuff for async loading. 
CreateFile,ReadFile, etx is what you would use.

We currently use a separate thread for loading at the moment and it works 
OK. However when trying to load from disk while running you do get 
significant slowdown even so, as this thread is heavily used, even when it's 
priority is low(ish). I figure the OS must be able to handle this better 
than me with an async load. If I had time I'd experiment a bit to see it 
this is the case.

Also async loads would be useful if data using being loaded from mulitple 
sockets rather than a simple file. But I really can't see this happening 
with physfs.

I'd just like to see it as an option.

Tree