Date: Tue, 28 May 2002 23:05:06 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c Message-ID: <XFMail.20020528230506.jhb@FreeBSD.org> In-Reply-To: <200205290129.g4T1TlXR009460@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-May-2002 Garrett Wollman wrote: > <<On Tue, 28 May 2002 20:00:19 -0400 (EDT), John Baldwin <jhb@FreeBSD.org> said: > >> And you are being completely vague about what the current strategy actually >> is. > > Non-blocking synchronization. Or rather, semi-non-blocking > synchronization. As written, except for this (minor) race, and given > the requirement for type-stable memory, we do not need any mutual > exclusion except for the initial construction of the list of sockets > to copy out. (If a better data structure were used for the list of > sockets, we would not need any mutual exclusion at all.) We can > provide to applications a limited form of consistency which was not > possible with the old (grovel in KVM) implementation, without blocking > network activity for an inordinate length of time. This isn't going to work on an SMP system. You can't just ignore what the other CPU's are doing in a system unless you want to use a Giant lock around the entire kernel. All I am proposing is that we just bump the reference count on the socket and then release it again, not that we keep the socket locked across the entire copyout. The socket would be locked for very short periods of time. In fact, depending on how the reference count is implemented it could even end up being simple atomic operations instead of very-shortly-held locks. > One would prefer that an appropriate constructor were used instead of > simply hoping for the best. (It's highly unlikely that the race would > be lost undetectably, so it's not a huge concern, but it is worthy of > a comment.) Define "an appropriate constructor" that can somehow make up for broken code on another process that is knowingly accessing stale pointers. In any case, I still maintain that the broken code worthy of an XXX is the sysctl code that is reading stale data, not a bzero in a soalloc! > -GAWollman -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020528230506.jhb>