From owner-cvs-all@FreeBSD.ORG Mon Jun 14 19:27:46 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B8916A4CE; Mon, 14 Jun 2004 19:27:46 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD0143D2D; Mon, 14 Jun 2004 19:27:45 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5EJQTeY038675; Mon, 14 Jun 2004 15:26:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5EJQTuU038672; Mon, 14 Jun 2004 15:26:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 14 Jun 2004 15:26:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20040614190412.GF61448@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c uipc_socket.c uipc_syscalls.c uipc_usrreq.c src/sys/net raw_cb.c raw_usrreq.c src/sys/netatm atm_socket.c src/sys/netatalk ddp_pcb.c src/sys/netgraph ng_ksocket.c src/sys/netgraph/bluetooth/socket ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 19:27:46 -0000 On Mon, 14 Jun 2004, Alfred Perlstein wrote: > * Robert Watson [040612 14:02] wrote: > > > > I'm not entirely happy with the assymetric locking here, but since these > > calls release references to the object, I think it makes some amount of > > sense. Right now, I opt to have the caller manage locking so that the > > impact of acquiring the socket lock is visible in the caller to discourage > > improper calling of these APIs. We might eventually want to push locking > > down into these APIs, but I don't think we want to do that yet. > > Assymetric locking is common with refcount based APIs when releasing > objects. Typically convention has been to have a function that drops an > unlocked object (fdrop) and one that takes a locked object for > convenience (fdrop_locked). I think this would be a useful convention to use in the socket code as well; in the netperf branch we have a number of _locked variants, although I've been trying to eliminate the need for some of the API variations gradually as the need for conditional locking is reduced. Right now, the "leading cause" of odd locking contortions is kqueue, since the same polling entry point from kqueue is used recursively as a result of a call kevent as is used from the kqueue() system call, meaning that sometimes a subsystem's per-object or per-subsystem lock will be held at entry to the polling function, and sometimes it won't. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research