Hi, On Sat, Jul 21, 2018 at 12:51:53AM +0200, Lukas Tribus wrote: > Hello, > > On Fri, 20 Jul 2018 at 15:58, Olivier Houchard <[email protected]> wrote: > > > > Hi LuKas, > > > > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote: > > > Hello Oliver, > > > > > > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard <[email protected]> > > > wrote: > > > > > > > > Hi, > > > > > > > > On Fri, Jul 20, 2018 at 12:22:20AM +0000, Thrawn wrote: > > > > > So...is there a way to adapt this patch so it won't cause random SSL > > > errors and is suitable to apply to the trunk? We don't really want to run > > > a > > > customised build in production... > > > > > > > > You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be > > > enough. > > > > > > I don't really understand, are you saying that the spinlock introduced > > > in cd1a526a doesn't work properly (as in: causes random SSL errors)? How > > > does this work on FreeBSD and OpenBSD? This sounds like a supported > > > configuration on a supported OS causes random SSL errrors when in > > > multiprocess mode, but I imagine I got something wrong here. > > > > > > Please help me understand this issue. > > > > > > > No, it works fine, but if you compile without USE_THREADS, the HA_ATOMIC* > > macroes I used in my patch are in fact not atomic at all, so that may cause > > random and unpredictable failures if the SSL cache code use them. > > Ok, I guess my question is, how can we improve this so that SSL cache > doesn't unpredictably fail? > Threading is a huge feature, but behaving unpredictably when threading > is disabled (or unsupported on the specific OS) is bad. > > Can't the code handle the SSL cache like it did before threading was > introduced, when threading is disabled? > >
My patch won't be applied, so it'll behave the exact same way it used to. Reading the 1.6 code, the calls to __sync_lock* were already there, so it probably did not compile on Solaris with a gcc older than 4.1, unless USE_PTHREAD_PSHARED was defined. Regards, Olivier
