[
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206845#comment-17206845
]
ASF GitHub Bot commented on GEODE-8553:
---------------------------------------
gaussianrecurrence commented on pull request #660:
URL: https://github.com/apache/geode-native/pull/660#issuecomment-703156801
Hi,
Ok... got it finally. After fighting 1-2 days with VS and the old testing
framework I located the problem.
Problem has to do with move semantics and ConnectionWrapper. Thing is for
some reason I forgot how to program and I implemented the movement of the conn_
attr just as conn_(std::move(other.conn_)) and whenever the original object
conn_ pointer is not nullptr, therefore the pointer is destroyed, leaving the
second object pointing to an invalid.
Thing is, it seems GCC implementation of the standard is different than
MSVC's and it avoids calling to the move constructor and that's why test were
passing in Linux.
Will upload a fix ASAP.
BR,
Mario.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Reduce ThinClientLocatorHelper lock time
> ----------------------------------------
>
> Key: GEODE-8553
> URL: https://issues.apache.org/jira/browse/GEODE-8553
> Project: Geode
> Issue Type: Improvement
> Components: native client
> Affects Versions: 1.12.0, 1.13.0
> Reporter: Mario Salazar de Torres
> Assignee: Mario Salazar de Torres
> Priority: Major
> Labels: pull-request-available
>
> During my troublshootings, I've seen that locking m_locatorLock for the whole
> scope of the class function members might cause some inter-locks.
> Problem here and in many other places of the NC is that networking operations
> are performed while a mutex is locked. Therefore if *thread A* takes longer
> than expected in performing its network operation, it might block another one
> which does not requires any resource of the first *thread A*. Hence, the
> inter-lock.
> This improvement is the first one of a series regarding to lock scope
> reduction when it comes with code regarding networking in NC.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
