Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | [svn-r2348] The way the pthread_t object was being initialized wasn't ↵ | Bill Wendling | 2000-06-06 | 1 | -1/+1 |
| | | | | | | | | | | | | 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' calls | Bill Wendling | 2000-05-19 | 1 | -14/+13 |
| | | | | | | | | | | | | | 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 Koziol | 2000-05-19 | 1 | -0/+54 |
HDF5 coding standards. |