physfs nonblocking bluesky.

Adam D. Moss adam at gimp.org
Tue Dec 16 13:33:59 EST 2003


I've been thinking, on and off for months, about async
reads using PhysicsFS.  My app has gotten to the stage
where it manually swaps resources of various types
(textures, sound fragments) in and out of caches on
demand instead of at level startup (the working set
is potentially massive and unknown ahead of time, this
being the reason for the app-level swapping).

This is fairly adequate in speed where the on-disk
resources live on the hard disk.  This is going to suck
amazingly for a game that is played from CDROM, however.
The caches have backup plans for when a resource is desired
in real time and not in the cache, but at some point soon
thereafter we really need to be actually-actually getting the
real thing off disk -- and then *woof*, >300ms blocking
seek across the CD/DVD, and a visible pause for I/O.

So, I've been pining for async-everything, which I was
expecting to (and possibly will, in the medium-term) implement
on top of physfs at the application level by shooting off
threads all of the place.  I/O and cpu stuff usually
parallelise very well.

But today I thought, hmm, I probably don't have to go crazy
with threads etc at the application level; all I really need
for this -- *probably* -- is for physfs to offer to open its
virtual files with the equivilent of O_NONBLOCK and attempt
to present some analogy of the unistd nonblocking-io semantics
to users.  To keep things relatively simple (and monothreaded),
physfs could consider any decompression phase to be free and
only return EAGAIN when physfs itself is waiting on real I/O.

So, that's my bluesky suggestion-or-request for some future
development of PhysicsFS.  This isn't critical or strictly
necessary -- it can likely be implemented at the application
level (thank goodness for physfs being threadsafe -- and
relatively non-contended; locking is per-physfs-virtual-
filehandle right?) but it would probably be a nicer platform
on which to build solutions for I/O in application which
can't afford to be put to sleep while waiting for anything.

Regards,
--Adam





More information about the physfs mailing list