From owner-freebsd-hackers  Sun Dec 17 14: 6: 5 2000
From owner-freebsd-hackers@FreeBSD.ORG  Sun Dec 17 14:06:02 2000
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28])
	by hub.freebsd.org (Postfix) with ESMTP id 17D7137B400
	for <hackers@FreeBSD.ORG>; Sun, 17 Dec 2000 14:06:02 -0800 (PST)
Received: from holly.dyndns.org ([208.191.149.190]) by mta4.rcsntx.swbell.net
 (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0G5Q00A3PG11SQ@mta4.rcsntx.swbell.net> for hackers@FreeBSD.ORG;
 Sun, 17 Dec 2000 16:05:25 -0600 (CST)
Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3)
 id QAA57043; Sun, 17 Dec 2000 16:04:43 -0600 (CST envelope-from chris)
Date: Sun, 17 Dec 2000 16:04:42 -0600
From: Chris Costello <chris@calldei.com>
Subject: Re: Why not another style thread? (was Re: cvs commit:
 src/lib/libc/gen getgrent.c)
In-reply-to: <20001217155648.C63080@hamlet.nectar.com>
To: "Jacques A. Vidrine" <n@nectar.com>
Cc: hackers@FreeBSD.ORG
Reply-To: chris@calldei.com
Message-id: <20001217160442.H54486@holly.calldei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.4i
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>
Sender: chris@holly.dyndns.org
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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