I'll try to come up with a patch that combines 1 and 2. So keep the qsort() example, but then add something along the lines of: "If you are not convinced that qsort requires locking in the library, consider the following example..." and then "Note the dangerous situation as the library releases its locks prior to invoking the user's callback function..." --Elad On Tue, 27 Sept 2022 at 15:06, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Mon, Sep 26, 2022 at 09:48:33PM -0400, Elad Lahav wrote: > > This started out as a longer email, but it looks like at least two of > > the problems I spotted were already fixed in the latest version. > > > > 1. I think the recommendation to release all locks before invoking a > > user-supplied function should come with a BIG FLASHING WARNING SIGN > > (or the PDF equivalent). Whenever I review code that releases and > > re-acquires a lock I look for the faulty assumptions it makes about > > state being preserved from before the lock was released. 9 out of 10 > > times I find a bug. > > Good point! > > Left to myself, I would add another infamous Quick Quiz. But would > you like to send a patch proposing something? > > > 2. qsort() may not be the best example to use in this section, as, > > even assuming there is some version of it that requires locks, the > > reader may fail to see any problems. While I'm no fan of nftw(), it > > may be easier to see why you would need a lock in the library (to > > prevent changes to the directory), as well as why releasing and > > re-acquiring the lock can be dangerous (the iterator can become > > invalid). > > This does sound better than qsort, so if no one has a better suggestion, I > would be tempted to go with that. In the absence of a better suggestion, > would you be willing to supply some sample code, preferably buildable > and executable? > > > 3. Page 106, first paragraph: "an pointer" should be "a pointer". > > This one was easy, so I applied it with your Reported-by. Good eyes, > by the way, and thank you! > > Thanx, Paul
