[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202351#comment-14202351
]
Powell Molleti commented on TS-3156:
------------------------------------
Hi Ryo,
Nice catch. I do not see any obvious issue with changes there:
- ink_scoped_mutex lock(ssl_plugin_mutex);
+ MUTEX_LOCK(lock, &ssl_plugin_mutex, this_ethread());
Can you add a debug log to print strerror() when pthread_mutex_lock(m) fails in
ink_mutex_acquire() in lib/ts/ink_mutex.h so we can see whats wrong with that
lock.
I am concerned I missed something here perhaps init_HttpProxyServer(int
n_accept_threads) is skipped hence the lock is not being initialized?. Since I
changed the lock from static initialization to initialize in module init code
in init_HttpProxyServer().
-static ink_mutex ssl_plugin_mutex = PTHREAD_MUTEX_INITIALIZER;
+static ProxyMutex ssl_plugin_mutex;
I think my assumption that init_HttpProxyServer() gets called first in this
module before other apis could be wrong. Let me send another patch that keeps
the previous static init stuff the same with the new locking code.
> Mutex[Try]Lock bool() operator change and unused API removal
> ------------------------------------------------------------
>
> Key: TS-3156
> URL: https://issues.apache.org/jira/browse/TS-3156
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Powell Molleti
> Assignee: James Peach
> Priority: Minor
> Labels: review
> Fix For: 5.2.0
>
> Attachments: MutexLock-ats.patch, MutexLock-ats.patch
>
>
> Removed unused constructor in MutexLock along with set_and_take() method, had
> to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
> default bool and ! operator from both MutexLock and MutexTryLock with
> is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
> base.
> Ran make test will be performing more system testing. Posted before for early
> comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
