On Thu, Aug 08, 2013 at 05:33:51PM -0700, Ethan Jackson wrote:
> Here's a new version. The most interesting thing is what I've done around
> oftable_remove_rule(). It wasn't strictly necessary, but it made clang thread
> safety a lot happier.
Thanks, this is more "obviously correct".
Acked-by:
Here's a new version. The most interesting thing is what I've done around
oftable_remove_rule(). It wasn't strictly necessary, but it made clang thread
safety a lot happier.
---
lib/classifier.c |3 ++
lib/classifier.h | 57 ---
ofproto/ofpr
I was having a lot of trouble getting the thread safety analysis to
work out with it, and I figured that since only the main thread
iterates or needs to take the write lock, we're safe. Let me revist
this though, I agree it's a wart.
Ethan
On Thu, Aug 8, 2013 at 3:14 PM, Ben Pfaff wrote:
> On T
On Thu, Aug 08, 2013 at 12:58:30PM -0700, Ethan Jackson wrote:
> Signed-off-by: Ethan Jackson
The bits of code in ofproto.c that iterate over classifier rules do
not take any classifier locks, but every other use of a classifier
(e.g. even classifier_is_empty()) does take the lock. I don't
under
