Bug fixes
Description:
All tests were core=dumping in IRIX64. The bug is in Generic
property list creation in which malloc asked for 2*64-1 bytes
due to coding bug. The object creation failed but the return
code was not checked. Program eventually crashed.
Solution:
H5F.c:
Check the return code from new file object creation and flag
error accordingly.
H5FL.c:
H5FL_arr_free is a replacement for H5MM_xfree which accepts
null value as a legal argument value. H5FL_arr_free assert
on it. Since other parts of the code have been passing null
value to H5MM_xfree, H5FL_arr_free must accept it too until
all the calling routines are changed to not pass Null.
H5P.c:
some routine passes in 0 as the hashsize value which is uintn.
The expression (hashsize-1) underflows to the largest unsigned
int for some machines. Thus the calloc failed. Cast hashsize
to unsigned int first (this assumes hashsize stays within the
signed int data range.
H5Smpio.c:
Added the extra parameter because the H5FD_write has been redefined.
Platforms tested:
IRIX64 -64 and -n32
hyperslab boundaries after adding them all, instead of maintaining the sorted
order during each addition. This boosts performance for sub-sampled (i.e.
strided) hyperslabs by about a factor of 10! :-)
added code to allow metadata to be allocated out of a more contiguous block
("metadata aggregation") and also code for "catching" small metadata write
calls and building a buffer of the small pieces of metadata for later writing
as one, larger, block ("metadata accumulation"). These features are enabled
on a per VFL driver basis with the new VFL 'query' call and both currently
enabled for the sec2, family and stdio drivers. The mpio VFL driver enables
only the "metadata aggregation" code, not the "metadata accumulation" code.
All the other drivers have these features turned off.
placed on how much memory is used by the free lists before they are garbage
collected. The default is to have no limit, with garbage collection only
occurring when they cannot allocate memory.
lists. Each kind of list one has hard-coded limits on when to garbage collect,
which will be replaced with user-controllable knobs (through property list
settings, I think) once I finish debugging some related performance problems.
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 :-).
cached instead of in separate structures. This reduces the amount of memory
the hash table uses by about half. This is the initial step along the path of
speeding up the metadata caching.
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.
