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>