On Fri, 2019-07-05 at 10:30 -0400, Alan Stern wrote: > I haven't looked at the new patches yet. > > Still, what I originally had in mind for this situation was that the > _last_ event should always take precedence. This goes against the idea > of having separate FSG_STATE_* levels for disconnect and config-change, > because the driver assumes that higher levels should override lower > levels. Right, this is what my new tentative patch does. The main caveat is to ensure that if that last event arrives after the previous one was "dequeued" by the thread but before it was *processed*, then we don't clobber it's argument (new_fsg) and thus end up processing both events each with the appropriate corresponding value of new_fsg. This is the root of the bug in fact: When the second event occurs in that window, we end up processing twice, as expected, but potentially using twice the *new* new_fsg value. > Also, if the thread has already started processing one of these events > when another one occurs, the new exception should cause the thread to > restart the handler and thus take care of the new event. And yes, > there should be enough locking to ensure that nothing gets stomped on > except in situations where it won't matter. > > That's how I think this should all work, and it doesn't look like we > really need a queue to do it properly. Yes, I agree. That's what the patch I posted last night aims at, I need to test it today. Cheers, Ben.
