From owner-cvs-all Thu May 2 12:48:31 2002 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C95FA37B41F; Thu, 2 May 2002 12:48:26 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g42Jm0Q4002398; Thu, 2 May 2002 21:48:00 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Jeff Roberson , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jeff Roberson Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/sys/vm uma_core.c In-Reply-To: Your message of "Thu, 02 May 2002 13:34:00 EDT." Date: Thu, 02 May 2002 21:48:00 +0200 Message-ID: <2397.1020368880@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , John Baldwin writes: >So I should amend: it should probably be ok to hold locks if M_NOWAIT is >used. However, we should avoid holding locks for "long" periods of time. >Esp. around non-relevant stuff like malloc (doing a malloc() usually isn't >very relevant to the consistency of the data structure, you should almost >always be able to make the structure consistent somehow, drop the lock, >malloc, then lock and make the change, or just malloc first before getting >locks and making changes). Well, for locks involving single data structures this might be true, but for locks which protect larger sets of data structures integrity this may just be plain impossible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message