On 01/09/14(Mon) 14:13, Philip Guenther wrote: > On Mon, 1 Sep 2014, Martin Pieuchot wrote: > > On 01/09/14(Mon) 09:31, Ted Unangst wrote: > > > On Mon, Sep 01, 2014 at 13:08, Mike Belopuhov wrote: > > > > On 1 September 2014 12:39, Philip Guenther <pguent...@proofpoint.com> > > > > wrote: > > > >> On Mon, 1 Sep 2014, Mike Belopuhov wrote: > > > >>> per the stack trace rwlock was tried to be acquired in the interrupt > > > >>> context which is a no-no. > > > >> > > > >> So you disagree with my diff > > > > > > > > right now i believe that the current behavior is correct since > > > > recursion is not supported on this lock and the diag check > > > > prevents you from making a mistake. mutex(9) works like that > > > > as well. > > > > > > I think passing NOSLEEP means the caller was trying not to make a > > > mistake either. > > > > I understand it differently, RW_NOSLEEP is not here to prevent locking > > against yourself, but against another process READing the map. Or is it > > ok now to grab a rwlock in interrupt context? > > Then don't rely on the if-you're-completely-unlucky "locking against self" > check and instead put that "okay to sleep?" assertion (whose name escapes > me) at the top of each of the rw_enter*() functions.
I like the idea but I can't tell how many things will blow (8 While we are discussing such things, what's the reason for having to different rw_* functions for each operation? I mean rw_enter() *and* rw_enter_read() + rw_enter_write()? I believe the plan to make them MD & atomic like the comment says was aborted, no? Is there a real performance gain by using the *should be MD and atomic* version? Couldn't we simplify this API?
