Date: Mon, 14 Jun 2004 12:04:12 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Robert Watson <rwatson@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 ... Message-ID: <20040614190412.GF61448@elvis.mu.org> In-Reply-To: <Pine.NEB.3.96L.1040612165841.90086Q-100000@fledge.watson.org> References: <200406122047.i5CKlWin099013@repoman.freebsd.org> <Pine.NEB.3.96L.1040612165841.90086Q-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Watson <rwatson@FreeBSD.org> [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). -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040614190412.GF61448>