| www.delorie.com/archives/browse.cgi | search |
> We rely on the fact that memory is available at the same location for > fork so if this breaks we have serious problems anyway. OK. I didn't think this would be a problem, but the documentation does specifically state that you can't rely on it. I assumed that if we did the allocation near program startup, we'd be able to get the same spot each time. > Also, as long as the memory doesn't contain internal references to > itself, you could get by with relocation. Not if it's shared. Relocating for one app would break the others. > It doesn't let you expand a region but you can use the same mechanism > as we do for the heap where you set aside a region but don't really > allocate it. Is that the option for non-committed mappings, with VirtualAlloc later? > If we are going to be inventing some kind of malloc-like allocation > in cygwin, it would be nice (tm) to also have a completely separate > malloc heap for cygwin itself. You mean a per-process cygwin-private heap? In addition to the global shared heap? Hmmm... > I think that we could generalize the malloc in newlib to handle > multiple heaps. We'd have to be careful not to break other newlib-using tools.
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |