aecd8471e1
more ref. count tracking and break some loops
2016-01-29 16:15:34 -05:00
03db900663
rework monitor queuing
2016-01-28 12:17:37 -05:00
9e92c67924
channel cache doesn't need to know about server provider
2016-01-28 12:16:30 -05:00
3e130d4f79
track and show server peer address
2015-12-08 22:01:38 -05:00
a2cbc6cae4
lock for ChannelCacheEntry
2015-12-08 20:30:29 -05:00
8abf5c20c6
more unlock monitor setup
2015-12-08 20:11:16 -05:00
3223c5da19
less locking during monitor setup
2015-12-08 18:10:06 -05:00
5e9ed37613
paranoia
2015-12-08 17:40:37 -05:00
810377aa34
lock for MonitorCacheEntry
2015-12-08 17:29:46 -05:00
3865745790
cleanup from dtor
...
Avoid unnecessary reset() of otherwise const shared_ptr in destroy()
as this necessities locking for potentially concurrent access.
2015-12-08 16:10:17 -05:00
9fe595722c
very tricky...
...
ChannelMonitorImpl is lobotomized with the smarts going
to MonitorStrategyQueue, both implementing Monitor.
While CMI proxies calls poll/release() to MQS,
it seems that MQS doesn't proxy destroy() to CMI.
So calling destroy() on MQS is a no-op...
2015-12-08 14:45:27 -05:00
ccdc51e417
monitor cache
2015-12-07 22:25:46 -05:00
c761c94bfc
break strong ref. loop between ChannelCache and GWServerChannelProvider
2015-09-09 17:03:06 -04:00
56d3b9b4e0
start
2015-09-08 17:06:31 -04:00
Michael Davidsaver