__uc_malloc

Denys Vlasenko vda.linux at googlemail.com
Wed Jun 11 18:53:27 UTC 2008


On Monday 09 June 2008 16:56, Bernd Schmidt wrote:
> It's really not a hard concept, this whole documented behaviour thing.
> 
> >> and infinitely better  
> >> > than crashing in the middle of a program and leaving things in an 
> >> > inconsistent state.  Even when you get OOM, there are different modes of 
> >> > failure,
> > 
> > On the microscopic level, yes, they are different.
> > 
> > In a bigger picture, no. The machine is unusable one way or another.
> 
> But what are the consequences of failure?  Okay, so I agree that a 
> production machine should be big enough not to go OOM.  Reality is more 
> difficult, maybe there's a memory leak somewhere, in any case OOM does 
> happen occasionally.  The question then becomes: where and how do we 
> fail, and what are the consequences.

Does the following change address your concern?

        while (1) {
                p = malloc(size);
                if (!size || p)
                        return p;
-               if (!__uc_malloc_failed)
-                       _exit(1);
+               if (!__uc_malloc_failed) {
+                       /* __uc_malloc is called from places where
+                        * we *must not* fail. The only other option
+                        * is to wait for out-of-memory condition
+                        * to abate.
+                        */
+                       usleep(50*1000); /* 50 ms, somewhat arbitrary */
+                       continue;
+               }
+               /* Call user's installed handler, if it returns, retry */
                __uc_malloc_failed(size);
        }
 }

This should be conforming to standards, it will never exit by itself.

Of course, it can now take arbitrarily long to complete if the box
is running out of memory, but standards say nothing about running time
of any function.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7.patch
Type: text/x-diff
Size: 797 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080611/1e2c3d06/attachment.bin 


More information about the uClibc mailing list