Updated comment on thread safety.

This commit is contained in:
Ryan C. Gordon 2002-03-30 17:26:03 +00:00
parent d5402e6b17
commit 179aadad27
1 changed files with 11 additions and 15 deletions

View File

@ -102,24 +102,16 @@
* PHYSFS_getBaseDir(), and PHYSFS_getUserDir() for info on what those * PHYSFS_getBaseDir(), and PHYSFS_getUserDir() for info on what those
* are and how they can help you determine an optimal search path. * are and how they can help you determine an optimal search path.
* *
* PhysicsFS is (sort of) NOT thread safe! The error messages returned by * PhysicsFS is mostly thread safe. The error messages returned by
* PHYSFS_getLastError are unique by thread, but that's it. Generally * PHYSFS_getLastError are unique by thread, and library-state-setting
* speaking, we'd have to request a mutex at the start of each function, * functions are mutex'd. For efficiency, individual file accesses are
* and release it before returning. Not only is this REALLY slow, it requires * not locked, so you can not safely read/write/seek/close/etc the same
* a thread lock portability layer to be written. All that work is only * file from two threads at the same time. Other race conditions are bugs
* necessary as a safety if the calling application is poorly written. * that should be reported/patched.
* 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.
* *
* While you CAN use stdio/syscall file access in a program that has PHYSFS_* * 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 * 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 * 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 * 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); __EXPORT__ PHYSFS_sint64 PHYSFS_fileLength(PHYSFS_file *handle);
#if 0 /* !!! FIXME: add this? */
#undef __EXPORT__
#endif
#ifdef __cplusplus #ifdef __cplusplus
} }
#endif #endif