[physfs] physfs nonblocking bluesky.

[Ryan C. Gordon]

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

O_NONBLOCK, to my knowledge, won't help with CD-ROM seek time, but I
could be wrong. I thought it was more for things like sockets where
there could be an infinite delay waiting on more data.

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

Physfs is thread safe (or at least, should be) as long as you don't try
to do i/o to the same file handle from two threads at once (in which
case, it might still be at the libc/OS level, but you can't really count
on which thread would get which data in that case anyhow.

Different files (and even different handles to the same file) can be
accessed in parallel, though, and other stuff, like directory access on
the same .zip file, etc, is safe from multiple threads.

--ryan.