Valgrind oddity.

[Adam D. Moss]

Hello!

==22066== pthread_mutex_destroy: mutex is still in use
==22066==    at 0x1B982A3D: pthread_error (vg_libpthread.c:380)
==22066==    by 0x1B984D32: pthread_mutex_destroy (vg_libpthread.c:1369)
==22066==    by 0x1BB01D84: closedir (in /lib/libc-2.2.4.so)
==22066==    by 0x80F6026: __PHYSFS_platformEnumerateFiles (posix.c:293)
==22066==    by 0x80F318B: DIR_enumerateFiles (dir.c:218)
==22066==    by 0x80F217C: PHYSFS_enumerateFiles (physfs.c:1489)
==22066==    by 0x80F184D: PHYSFS_setSaneConfig (physfs.c:1111)
==22066==    by 0x8052B9F: init_fileio (main.c:106)
==22066==    by 0x8053F49: main (main.c:833)

I've been noticing this for as long as I've been valgrinding,
but didn't know what to make of it.  It doesn't seem to have
caused me any harm but I thought it worth pointing out.

n.b. I've compiled physfs without pthreads support.  My app
doesn't use threads explicitly (it does use OpenAL which
implicitly uses threads, but OpenAL has no interaction with
physfs).

Anyone know if this worth worrying about?  I'm not even sure
I see why/how closedir() should be calling pthread_mutex_destroy().

Thanks,
--Adam
-- 
Adam D. Moss   . ,,^^   adam at gimp.org   http://www.foxbox.org/   co:3
"Some of the statements we have made as CRASS make me shudder at the
  degree of naivete expressed, but I wouldn't put them down, ever, or
  say that any of them were wrong."