> On Apr 28, 2015, at 10:31 AM, Jed Brown <[email protected]> wrote: > > 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? > Accessor? What is accessor?
>> 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.
