Re: phk malloc, was (Re: ptmalloc2)
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
討論串 (同標題文章)
完整討論串 (本文為第 14 之 57 篇)：