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 ...

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research