Date: Mon, 14 Jun 2004 15:26:29 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Alfred Perlstein <alfred@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: <Pine.NEB.3.96L.1040614152439.34947E-100000@fledge.watson.org> In-Reply-To: <20040614190412.GF61448@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Jun 2004, Alfred Perlstein wrote: > * 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). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040614152439.34947E-100000>