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

[Alfred Perlstein]

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



-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright at mu.org cell: 408-480-4684