On Sat, 9 Feb 2002, Julian Elischer wrote:
> On Sun, 10 Feb 2002, Bruce Evans wrote:
>
> > On Fri, 8 Feb 2002, Julian Elischer wrote:
> ...
> > > and in userret() and ast()
> > >
> > > >#ifdef DEBUG /*your choice of variable here*/
> > > > if (td->td_ucred != NULL) {
> > > > mtx_lock(&Giant);
> > > > crfree(td->td_ucred);
> > > > td->td_ucred = NULL;
> > > > mtx_unlock(&Giant);
> > > > }
> > > >#endif
> >
> > I think this is better left where it is in the functions that aquire
> > the locks. It can then be done unconditionally, and not in a loop.
>
> AST is not always called
> and userret is always called, but unfortunatly sometimes multiple times
userret() isn't always called either in my version :-). When I'm
finished, it will never be called (but I might rename ast() to userret()
since it is essenttially the unusual case for the original userret()).
> if someone were to clean up AST/userret
> it would be easier, but I am not sure I understand all the issues..
>
> Particularly the interraction between ast() and userret() and the various
> possible ASTs
Logically, it belongs at the end of userret(), but I would prefer it
to be immediately after all calls to userret() like it almost is now
so that I don't have to change it. ast() is not special here, modulo
optimizations -- it is just one caller of userret(). Think of it as
just an optimization of once case of trap().
> > The style of the null pointer check in this is bug for bug compatible
> > with the corresponding one above.
>
> which way would you prefer?
I prefer explicit comparisions with NULL and 0 except for booleans.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
