On Sat, 10 Jun 2000, Doug Rabson wrote:
> > Well if we get an atomic_t it could be done that way, even if we
> > fail the race for updating and go beyond our rlimit slightly it's
> > much cheaper than a spinlock from my PoV. The only problem is
> > that afaik on some archs atomic_t can be quite small, we'd have
> > to watch for overflow, perhaps a spinlock is a better idea however
> > only if the next thing I mention here is realized:
>
> You can use atomic_add_*() to do safe arithmetic on memory locations.
Yeah, but rlim_t isn't small enough to do that on an i386 :( Anyway,
I don't think race conditions will ever really happen with the code,
since the only interrupts that can modify sbsize are the PF_LOCAL
ones, and those are (AFAIK) synchronous.
> --
> Doug Rabson Mail: [EMAIL PROTECTED]
> Nonlinear Systems Ltd. Phone: +44 20 8442 9037
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
