Thread Safety

[ghost]

PhysFS can cause segmentation faults if certain functions are not locked. A major source seems to be de_init(). At the moment I have a PhysFSContext grab a global lock in the constructor and release it in the destructor, which also calls de_init(). However, this can lead to extremely poor performance.

It shouldn't matter how many PhysFSContexts are created, as long as they lock on file operations and de_init() is only called when 0 are left. Is there a way to do this kind of static instance counting without a static mut NUM_CONTEXTS : uint?

Additionally, the PhysFS mailing list says that using a single file handle across multiple threads will not work, and you should open a different file handle in each thread.

[TyOverby]

According to this, having two file handles is fine, it's just that it is unsafe to use a single handle from multiple threads at the same time. You'd need to get a new handle.

What this means in rust is that moving ownership (even to another thread) is perfectly fine. If you want to copy() a handle, it would need to get a new handle, which we might be able to do automatically.

[cirla]

According to this,

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.

I don't think the physfs::file::File operations should all share the same static lock with physfs::PhysFSContext, as they do now, but perhaps a separate mutex per File instance.

Also, this leads me to believe the lock is unnecessary in all of the physfs::PhysFSContext methods except new() and drop() for ref-counting the number of calls to PHYSFS_init().