Barry Smith <[email protected]> writes: > For things like we talked about the other day. Malloc zones, > .... maybe some indication that it is ok that the runtime take back > this memory if available memory is running low,
How do you communicate to the accessor that the memory has been freed? > the ability to turn off read or all access to a malloc zone so that > another library cannot corrupt the data, etc. When I said > independent of memkind I meant having nothing to do with memkind. Sure, and I'm not opposed to the concept, but I'd like it to somehow be based on information that the caller can use and have semantics that are implementable. I'm also not wild about the global variables like PETSC_COMM_WORLD (whose use is pretty much always wrong in library code), so would like to know how a relevant context would be plumbed into the caller's scope. > You are correct that involves lots of nonlocal information or information > that is not yet known, so the argument cannot be simple flags but must be a > context that can be modified at later times. Crude example > > malloc(zone1, n,&x); > .... > ZoneSetReadOnly(zone1); This is implementable, just somewhat expensive. > ZoneSetAvailableIfNeeded(zone1); I don't know what semantics this could have that wouldn't be a programming disaster.
signature.asc
Description: PGP signature
