Yes, this is the correct fix. In earlier versions, the core would create the mutex for you if it needed one, but this had some pretty expensive overhead. So now we just assert instead, so people can fix their plugins (and our plugins apparently).
Fwiw, the mutex is needed when the continuation uses a specific set of APIs. This should be documented in the docs somewhere. Cheers, -- Leif > On Jun 21, 2017, at 8:18 PM, John Rushford <jjrushf...@gmail.com> wrote: > > > Peter, > > I've found this with a couple of other plugins and fixed them by making > exactly the change you you're asking about. In testing i have not run into > any issues with the plugins i have changed. > > John > >> On Jun 21, 2017, at 4:22 PM, Chou, Peter <pbc...@labs.att.com> wrote: >> >> Hi, >> >> I am taking a look at the collapsed_connection plugin. There appears to be >> an assertion failure crash incompatibility between this plugin and changes >> made in the 6.2.x branch. TS-4387 appears to require all continuations >> calling TSContSchedule() to have a mutex, but in the plugin no mutex is >> created in addMutexRetry() since TSContCreate() is called as >> TSContCreate(retryCacheUrlLock, NULL). >> >> Is it sufficient to change this call to TSContCreate(retryCacheUrlLock, >> TSMutexCreate())? >> >> Would this possibly cause side-effects such as mutex lock contention the >> plugin is not designed to deal with, and would the mutex need to be >> destroyed manually somewhere else in the code? I am still learning on this >> area of ATS... >> >> Thanks, >> Peter
