Date: Sat, 12 Jun 2004 17:00:48 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, 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.1040612165841.90086Q-100000@fledge.watson.org> In-Reply-To: <200406122047.i5CKlWin099013@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Jun 2004, Robert Watson wrote: > - Note that sofree()/sotryfree() will release the socket lock even if > they don't free the socket. Colin and Bosko have pointed out that this note should also mention sorele(), which has similar properties. If the socket is still allocated when the macro returns, sorele() will release the lock on that socket. 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. The assertions in the functions will occasionally force slightly stronger locking than needed -- for example, it forces locks to be held in soalloc() and sodealloc() that may not actually be needed. I'll revisit this once I've got the basic locking merged. 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.1040612165841.90086Q-100000>