trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jamespe...@me.com>
Subject Re: optional continuation mutexes?
Date Thu, 20 Dec 2012 06:43:53 GMT
On 19/12/2012, at 10:15 PM, James Peach <jpeach@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

Mime
View raw message