[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About memory allocation failures....
From:       Rodolfo Conde Martinez <rcm () gmx ! co ! uk>
Date:       2002-01-30 0:12:14
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 January 2002 16:23, Alex Hayward wrote:
> On Tue, 29 Jan 2002, Schmidt, John wrote:
> > Rodolfo Conde Martinez
> >
> > > 	mmmhh.....havent check all the kde code....but isnt it free of
> >
> > exception
> >
> > > checking (as it does code bigger and slower doesnt it ?? )....and i
> > > guess
> >
> > not
> >
> > > all compilers have the -fno-check-new and -fno-exceptions like g++, so
> > > if there isnt exception checking what happens ? the program just
> > > crashes ??? wouldnt be a good idea to set a function handler in the
> > > kdelibs maybe or a
> > >
> > > handler apropiated for each app ??
> >
> > If a compiler doesn't return an error/exception upon failed allocation of
> > an object
> > due to short-on-storage... BAAAAAAAAAAD compiler, and I'd suggest finding
> > another.  As far as not coding for exceptions... BAAAAAAD coding!!  It
> > should only be slower (if you can notice it) when an exception occurs,
> > which hopefully won't be often!
>
> There is actually a performance penalty when you enter a try { .. } catch
> block. It's small, though.
>
> However, catching bad_alloc solves the wrong problem. malloc()/new use
> sbrk and/or mmap. Consequently they only fail if the process can't
> allocate *address space*. This is only likely to happen if you hit a
> resource limit on virtual size, the 2/3/4GB per process limit or your page
> tables are full. This might happen and you might wish to handle this...but
> this isn't the case you have in mind.
>
> Running out of memory doesn't happen during malloc/new. It happens when
> the OS tries to allocate a physical page to back virtual memory that has
> already been given to you via malloc/new. This happens when you first
> access the memory that malloc/new has returned. The OS responds by sending
> you a SIGSEGV. Your program never gets to see an allocation failure. In
> fact, my experience with Linux has been that the user gets bored of the
> swapping and resets the computer /long/ before swap space is exhausted.
>
> The only way out of this is to turn overcommit off in your OS. Not many
> OSs can do this (neither Linux or FreeBSD is one). It's also not usually a
> very useful thing to do most of the time.
>

	Yes youre right, so i think i'll be removing the NULL returning checks from 
my apps, well all that they taught me at school about always checking for 
malloc/new was pointless afther all.....or well not that bad as i supose its 
good programming practice but of course with a little performance 
penality....


	Cheers....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Vzphx2Sktruwba0RAgQfAKDcOoVWyijIoJ+lIj75Vphx4fz29ACg5lYi
ROYp3KEuHQVgh6yNKiHi+xs=
=NQYM
-----END PGP SIGNATURE-----


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]