Richard Mills <[email protected]> writes: > I think it is possible to add the memkind support without breaking all of > the interfaces used throughout PETSc for PetscMalloc(), etc. I recently > sat with Chris Cantalupo, the main memkind developer, and walked him > through PETSc's allocation routines, and we came up with the following: The > imalloc() function pointer could have an implementation something like > > PetcErrorCode PetscMemkindMalloc(size_t size, const char *func, const char > *file, void **result) > > { > > struct memkind *kind; > > int err; > > > > if (*result == NULL) { > > kind = MEMKIND_DEFAULT; > > } > > else { > > kind = (struct memkind *)(*result);
I'm at a loss for words to express how disgusting this is. > This gives us (1) a method of passing the kind of memory without modifying > the petsc allocation routine calling sequence, Nonsense, it just dodges the compiler's ability to tell you about the memory errors that it creates at every place where PetscMalloc is called! What did Chris say when you asked him about making memkind "suck less"? (Using shorthand to avoid retyping my previous long emails with constructive suggestions.) > and (2) support a fall back code path legacy applications which will > not set the pointer to NULL. Or am I missing something?
signature.asc
Description: PGP signature
