summaryrefslogtreecommitdiffstats
path: root/src/H5TS.c
Commit message (Collapse)AuthorAgeFilesLines
* [svn-r3781] Purpose:Bill Wendling2001-04-051-3/+3
| | | | | | | | | | | | | | | | | | 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
* [svn-r3677] Purpose:Albert Cheng2001-03-201-4/+0
| | | | | | | | | | | | | 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.
* [svn-r2348] The way the pthread_t object was being initialized wasn't ↵Bill Wendling2000-06-061-12/+25
| | | | | | | | | | | | 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 :-).
* [svn-r2286] Gave the threading functions return types (herr_t). pthreads' callsBill Wendling2000-05-191-80/+150
| | | | | | | | | | | | | 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.
* [svn-r2276] Modifed thread-safety code to more closely align with rest of ↵Quincey Koziol2000-05-191-85/+113
| | | | | | HDF5 coding standards.
* [svn-r2264] Added Thread-safe feature. This is the phase 1 implementationChee-Wai Lee2000-05-181-0/+243
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