Date: Thu, 30 Aug 2001 22:06:52 -0400 (EDT) From: Mike Silbersack <silby@silby.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG>, <cvs-committers@FreeBSD.ORG> Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_sem.c Message-ID: <Pine.BSF.4.30.0108302159470.19462-100000@niwun.pair.com> In-Reply-To: <200108310100.f7V10WG61314@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Aug 2001, Matt Dillon wrote: > :You could probably minimize a lot of these diffs using a UGAR() macro similar > :ot BSD/OS's EGAR macro. It unlocks Giant and then returns the value passed in. > :Thus return(foo); becomes UGAR(foo); > : > :This would make the diffs much simpler, which also makes it easier to take > :Giant out of syscalls later on: > : > :#define UGAR(rval) do { \ > : int _val = (rval); \ > : mtx_unlock(&Giant); \ > : return (_val); \ > :} while (0) > > I think it's better to keep it explicit. I don't want to hide the > fact that I am manipulating Giant. > > -Matt There could be cases where you'd want to drop Giant earlier than at the end of the function too, I suppose. (Possibly in cases where you only need Giant to grab certain pieces of data, then can go on with a more local mutex.) Actually, I guess now would be a good time to ask. Is grabbing Giant late / dropping it early a problem? I ask because I'm unclear if it's bad to have a function that's only part Giant-dependant. Obviously you could introduce races / other nasty conditions by not encapsulating the whole function in Giant - the question above is stated assuming that you have not introduced any races / bugs. :) Mike "Silby" Silbersack 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?Pine.BSF.4.30.0108302159470.19462-100000>