Date: Sun, 17 Dec 2000 16:04:42 -0600 From: Chris Costello <chris@calldei.com> To: "Jacques A. Vidrine" <n@nectar.com> Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <20001217160442.H54486@holly.calldei.com> In-Reply-To: <20001217155648.C63080@hamlet.nectar.com> References: <200012172110.eBHLAfU46563@freefall.freebsd.org> <20001217151509.A63051@hamlet.nectar.com> <20001217151735.D54486@holly.calldei.com> <20001217153129.B63080@hamlet.nectar.com> <20001217153656.F54486@holly.calldei.com> <20001217155648.C63080@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, December 17, 2000, Jacques A. Vidrine wrote: > I may have missed your point ... or maybe you are just agreeing with > what I wrote. For this particular implementation of free, you get the > following for `free(foo)' when foo == NULL: > > function call and stack overhead for free() > lock something if we are threaded > pointer assignment > increment > compare and branch > function call and stack overhead for ifree() > compare and branch > unwind ifree() > More stuff if HAVE_UTRACE > decrement > unlock something > unwind free() > FreeBSD's free() is not optimized for freeing NULL pointers. Not > that I think it should be -- as I said, that would be silly. The code I pasted _was_ FreeBSD's code, and it does optimize for freeing NULL pointers. You can still check for the pointer if you wish, before you call free(). -- +-------------------+-------------------------------------+ | Chris Costello | Backups? We doan *NEED* no | | chris@calldei.com | steenking baX%^~,VbKx NO CARRIER | +-------------------+-------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001217160442.H54486>