| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup & minor optimization
Description:
Re-work the way interface initialization routines are specified in the
library to avoid the overhead of checking for them in routines where there is
no interface initialization routine. This cleans up warnings with gcc 3.4,
reduces the library binary size a bit (about 2-3%) and should speedup the
library's execution slightly.
Platforms tested:
FreeBSD 4.10 (sleipnir) w/gcc34
h5committest
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Clean up code a bit
Chase new error API by including the error class in calls to H5E_push()
Platforms tested:
h5committested
|
| | |
|
| |
|
|
| |
Platforms tested: RH 8(simple checkin)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Update
Description:
Updated copyright statement in files which hadn't been updated yet.
Platforms tested:
Linux (Only comment change)
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New feature for developers.
Description:
Added "function stack" tracing to library. This allows developers (there
is no public API) to call H5FS_print within the library and get a listing
of the functions traversed to reach that point in the library. Eventually,
I may add support for reporting the parameters to each function also...
Mainly for debugging parallel I/O programs, but I think it will come in
handy in other cases also.
The function stack tracking is controlled with a configure switch:
--enable-funcstack, which defaults to enabled currently. When we branch
for 1.6, we should change the default setting on the branch to be disabled.
Also, added a destructor to the thread-specific keys when thread-safety is
turned on in the library. Otherwise, they were leaking memory and causing
difficult to debug errors in threaded programs (like the test/ttsafe test).
Platforms tested:
Tested h5committest {arabica (fortran), eirene (fortran, C++)
modi4 (parallel, fortran)}
FreeBSD 4.7 (sleipnir) w/thread-safety enabled.
Misc. update:
Updated MANIFEST with new files added (src/H5FS.c & src/H5FDprivate.h)
Update release_docs/RELEASE with thread-safety bug fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update
Description:
Changed
#include <hdf_file.h>
construct to
#include "hdf_file.h"
so that the GNU compiler can more easily pick up the dependencies
which it places in the .depend and Dependencies files. Also
regenerated the Dependencies to go along with this.
Platforms tested:
Linux
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug fix (sort of)
Description:
The RCSID string in H5public.h was causing the C++ code problem as it
was included multiple times and C++ did not like multiple definitions
of the same static variable.
Solution:
Since we don't really make use of the RCSID strings as we have not
installed it in all source files, we decided to remove it.
Platforms tested:
eirene (linux), modi4 (IRIX64-64) both serial and parallel modes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
correct for all
platforms. Also, it's not entirely certain that a value of 0 isn't a
valid thread ID. So, I changed the pthread_t object to be a pointer to
pthread_t with the appropriate memory management this entails. Part of
the validity of this approach rests on the fact that one can assign a
variable which is a structure to another variable of the same type and
all fields within will be copied appropriately...See! C *does* do some
things correctly :-).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
return 0 on success and non-zero on failure. That's what happens with
these calls.
There was a problem compiling threading on Linux. The pthread_t type is
not consistent among different implementations, so it cannot simply be
assigned to NULL or tested against it. I initialize it by calling
HDmemset(foo_thread, 0, sizeof(pthread_t)). To see if it's a "null"
pthread, I created a special pthread_t object (assigned to only in the
init phase and then only read...i.e., thread safe) and assigned it "null"
as above. Then I use pthread_equal() to determine if the thread is null.
|
| |
|
|
|
|
| |
HDF5 coding
standards.
|
|
|
that all HDF5 API functions are protected by a mutex lock. Basically,
serialized all API calls. To use it, use
configure --enable-threadsafe --with-pthread
|
