[asterisk-scf-dev] CR-ASTSCF-93: More long-instead-of-int changes.

[Crucible - All Open Reviews]

Mark Michelson![AUTH][1], Brent Eagles, Ken Hunt, Joshua Colp.

This makes use of a thread pool in the SIP session gateway. Operations fall
into one of two categories


1. Some operations originate over Ice. These operations are queued into
operations in SipSession.cpp. These operations derive directly from
SuspendableWork and are relatively straightforward in their operation.


2. Some operations originate from PJSIP callbacks. These are queued into
operations in PJSipSessionModule.cpp. These operations derive from a helper
class called SipQueueableOperation. The reason for this is that many of the
operations that originate from PJSIP callbacks make AMI calls to session
listeners. The results of these AMI calls need to be processed in our threads
and not within the Ice client threads.


Two major changes were made outside the SIP component.


1. Many Session methods have been changed to use AMD. All methods that return
non-void or that may throw an exception (or both) have been converted to use
AMD. This is why there are changes in the routing component's test and in the
test channel.


2. The PoolListener has been modified to run a hook when a thread is created
or destroyed. The purpose of this is so that thread-specific data may be
created or destroyed if necessary. In our case, we do this because pjlib
requires us to register all threads with pjlib before making any pjlib calls.
This is why the ice-util-cpp changes are included on this review.


The actual threading methodology in the SIP component is a bit on the dodgy
side for now, since my main objective was to get things working, not to
optimize. It basically runs under the principal of matching the number of
active threads to the number of operations in the threadpool's queue. This
roughly correlates to the number of sessions, but when the number can dip
lower if a session has no operations queued.


The code here is written not necessarily to be beautiful at the moment. I
certainly welcome suggestions regarding moving operations to different files
and renaming variables, but I'd prefer primary focus to be on the correctness
of the code.


I've tested to be sure that inbound and outbound calls work as expected. There
are some issues, but I have deduced that the problems are outside of the SIP
component. I did not test transfers or state replication.

**Under Review**

   [1]: https://code.asterisk.org/code/static/ll08f6/images/icn_author.gif

URL: http://code.asterisk.org/code/cru/CR-ASTSCF-93