Skip to content
Browse files
Updated comment on thread safety.
  • Loading branch information
icculus committed Mar 30, 2002
1 parent d5402e6 commit 179aadad27064460ea41e4f1e058c6ff50a8e51c
Showing with 11 additions and 15 deletions.
  1. +11 −15 physfs.h
@@ -102,24 +102,16 @@
* PHYSFS_getBaseDir(), and PHYSFS_getUserDir() for info on what those
* are and how they can help you determine an optimal search path.
* PhysicsFS is (sort of) NOT thread safe! The error messages returned by
* PHYSFS_getLastError are unique by thread, but that's it. Generally
* speaking, we'd have to request a mutex at the start of each function,
* and release it before returning. Not only is this REALLY slow, it requires
* a thread lock portability layer to be written. All that work is only
* necessary as a safety if the calling application is poorly written.
* Generally speaking, it is safe to call most functions that don't set state
* simultaneously; you can read and write and open and close different files
* at the same time in different threads, but trying to set the write path in
* one thread while opening a file for writing in another will, at best,
* cause a polite error, but depending on the race condition results, you may
* get a segfault and crash, too. Use your head, and implement you own thread
* locks where needed. Also, consider if you REALLY need a multithreaded
* solution in the first place.
* PhysicsFS is mostly thread safe. The error messages returned by
* PHYSFS_getLastError are unique by thread, and library-state-setting
* functions are mutex'd. For efficiency, individual file accesses are
* not locked, so you can not safely read/write/seek/close/etc the same
* file from two threads at the same time. Other race conditions are bugs
* that should be reported/patched.
* While you CAN use stdio/syscall file access in a program that has PHYSFS_*
* calls, doing so is not recommended, and you can not use system
* filehandles with PhysicsFS filehandles and vice versa.
* filehandles with PhysicsFS and vice versa.
* Note that archives need not be named as such: if you have a ZIP file and
* rename it with a .PKG extension, the file will still be recognized as a
@@ -866,6 +858,10 @@ __EXPORT__ int PHYSFS_seek(PHYSFS_file *handle, PHYSFS_uint64 pos);
__EXPORT__ PHYSFS_sint64 PHYSFS_fileLength(PHYSFS_file *handle);

#if 0 /* !!! FIXME: add this? */
#undef __EXPORT__

#ifdef __cplusplus

0 comments on commit 179aada

Please sign in to comment.