On 19/12/2012, at 10:15 PM, James Peach <[email protected]> wrote: > Hi all, > > From the HttpAccept comments, it looks like it used to be optional for > continuations to have a mutex. It no longer is, since if I remove the mutex > from SSLNextProtocolAccept, traffic_server segfaults trying to lock it: > > * thread #26: tid = 0x3303, 0x000000010ab6dae4 > traffic_server`Mutex_lock(ProxyMutex*, EThread*) + 20 at I_Lock.h:266, stop > reason = EXC_BAD_ACCESS (code=1, address=0x50) > frame #0: 0x000000010ab6dae4 traffic_server`Mutex_lock(ProxyMutex*, > EThread*) + 20 at I_Lock.h:266 > frame #1: 0x000000010abbecb7 > traffic_server`MutexLock::MutexLock(ProxyMutex*, EThread*) + 71 at > I_Lock.h:335 > frame #2: 0x000000010abbbb75 > traffic_server`MutexLock::MutexLock(ProxyMutex*, EThread*) + 37 at > I_Lock.h:336 > frame #3: 0x000000010ad8feef > traffic_server`SSLNextProtocolAccept::mainEvent(int, void*) + 207 at > SSLNextProtocolAccept.cc:129 > frame #4: 0x000000010ab6c377 traffic_server`Continuation::handleEvent(int, > void*) + 119 at I_Continuation.h:146 > frame #5: 0x000000010ada3da2 > traffic_server`UnixNetVConnection::acceptEvent(int, Event*) + 786 at > UnixNetVConnection.cc:974 > > Is there a good reason for this change? Is there a recommended pattern for > dealing with an optional continuation mutex?
Sigh ... of course, I'm the one who added in the mutexes. Soon I'll post a patch to remove them. J
