Date: Tue, 28 May 2002 21:29:47 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c Message-ID: <200205290129.g4T1TlXR009460@khavrinen.lcs.mit.edu> In-Reply-To: <XFMail.20020528200019.jhb@FreeBSD.org> References: <200205282306.g4SN60YG008784@khavrinen.lcs.mit.edu> <XFMail.20020528200019.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<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. 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.) -GAWollman 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?200205290129.g4T1TlXR009460>