You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2012/12/20 07:15:11 UTC
optional continuation mutexes?
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?
J
Re: optional continuation mutexes?
Posted by James Peach <ja...@me.com>.
On 19/12/2012, at 10:15 PM, James Peach <jp...@apache.org> 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