Date: Thu, 15 Apr 1999 00:38:21 -0400 (EDT) From: Mikhail Teterin <mi@kot.ne.mediaone.net> To: imp@harmony.village.org (Warner Losh) Subject: Re: swap-related problems Message-ID: <199904150439.AAA28222@kot.ne.mediaone.net> In-Reply-To: <199904150432.WAA07661@harmony.village.org> from Warner Losh at "Apr 14, 1999 10:32:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh once stated: =: Then, one can write a safe malloc, which will install the signal =: handler, and touch every page in the the memory referenced by the =: to-be-returned pointer. If the signal handler is invoked in the =: progress, the to-be-returned memory must be returned back to the =: system and NULL should be returned to the caller. =This won't work all the time. FreeBSD overcommits swap space and you =may get a SIGKILL even if you've touched all the pages. FreeBSD kills =processes when swap space runs out. That's my point! I advocate the use of some _other_ signal. Something catchable. =: However, my (in)ability to propose anything remotely sensible does =: not change the facts established in this painful thread. That our =: malloc does not conform to standards (for whatever reasons), and that =: something should be done about it. That "something" must start with =: documenting the flaw... =The behavior is documented: = The malloc() and calloc() functions return a pointer to the allocated = memory if successful; otherwise a NULL pointer is returned. = =What the system does when it has resource shortages is beyond the scope =of the ANSI-C standard, so I don't see why you say that FreeBSD's =malloc isn't standard conforming. In case of "resource shortage" the malloc should be unsuccessful and return NULL. Instead, right now you may still get a non-NULL pointer, but get a SIGKILL when you try to use the rightfully allocated memory. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904150439.AAA28222>