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
