phk malloc, was (Re: ptmalloc2)

[Bill Hacker]

Dan Melomedman wrote:
Matthew Dillon wrote:

   program that would benefit from it.  Not one.  The answer is:  libc
   has no support for it because 99.9% of the programs that exist in this
   world have no use for it and would not benefit from it.  If you want


I disagree with you about the benefits. If an email proxy will lose
messages because it can't make certain memory guarantees through the OS,
I can't use that OS with the email proxy in question.
If the 'email proxy in question' is that fragile - your statement would 
appear to be true.

Let's take it as stipulated.

But - having spent several years on the lists of the 'major' MTA's and 
related mail packages (IMAP, POP, etc.)
and their filters, I don't seem to recall this sort of problem being an 
issue anywhere, on any of several OS'.

Moreover, it doesn't seem to be a general cause of crash or failure in 
UNIX apps in general.

When well-written, they take account of the potential for conflicts and 
restricted resources in their environment to either try again, 
fall-back, or at least warn and exit cleanly.


   total control over the backing store for a program's memory there is
   nothing stopping you from writing your own malloc wrapper to wire the
   memory or to use a file-backed mmap or something like that.
   The plain fact of the matter is that for any system where it matters,
   the person running the program will set a datasize limit or the program
   itself will be self-regulating.


In MessageWall the buffer size is user-configurable. The problem is the
OS just won't give that physical memory to MessageWall. People don't want to
possibly lose or delay email due to memory errors. It's just not acceptable.
So to summarize, the malloc feature I am looking for simply doesn't exist in
*BSD, and I should be looking elsewhere, or write a malloc replacement?
Would it not be easier to select, not write, a replacement for MessageWall?
- or whatever other application is that fragile / out-of-step with it's 
environment?

If a fully deterministic OS is required, none of the Unices are going to 
'be there' all the time - not just w/r memory - but any physical 
resource that must serve the needs of more than just one application.

'Dedicated resources' falls into the territory of state machines - 
ASIC's, gate-arrays, solder, even.
Noteworthy for predictability, but hardly for flexibility.

JMTCW

Bill Hacker