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 Mon, 14 Jun 2004, Alfred Perlstein wrote:

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