[Asterisk-code-review] res pjsip: Add serialized scheduler (res pjsip/pjsip schedu... (asterisk[master])

[George Joseph]

Hello Mark Michelson, Anonymous Coward #1000019, Joshua Colp,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/2486

to look at the new patch set (#6).

Change subject: res_pjsip:  Add serialized scheduler (res_pjsip/pjsip_scheduler.c)
......................................................................

res_pjsip:  Add serialized scheduler (res_pjsip/pjsip_scheduler.c)

There are several places that do scheduled tasks or periodic housecleaning,
each with its own implementation:

* res_pjsip_keepalive has a thread that sends keepalives.
* pjsip_distributor has a thread that cleans up expired unidentified requests.
* res_pjsip_registrar_expire has a thread that cleans up expired contacts.
* res_pjsip_pubsub uses ast_sched directly and then calls ast_sip_push_task.
* res_pjsip_sdp_rtp also uses ast_sched to send keepalives.

There are also places where we should be doing scheduled work but aren't.
A good example are the places we have sorcery observers to start registration
or qualify.  These don't work when changes are made to a backend database
without a pjsip reload.  We need to check periodically.

As a first step to solving these issues, a new ast_sip_sched facility has
been created.

ast_sip_sched wraps ast_sched but only uses ast_sched as a scheduled queue.
When a task is ready to run, ast_sip_task_pusk is called for it. This ensures
that the task is executed in a PJLIB registered thread and doesn't hold up the
ast_sched thread so it can immediately continue processing the queue.  The
serializer used by ast_sip_sched is one of your choosing or a random one from
the res_pjsip pool if you don't choose one.

Another feature is the ability to automatically clean up the task_data when the
task expires (if ever).  If it's an ao2 object, it will be dereferenced, if
it's a malloc'd object it will be freed.  This is selectable when the task is
scheduled.  Even if you choose to not auto dereference an ao2 task data object,
the scheduler itself maintains a reference to it while the task is under it's
control.  This prevents the data from disappearing out from under the task.

There are two scheduling models.

AST_SIP_SCHED_TASK_PERIODIC specifies that the invocations of the task occur at
the specific interval.  That is, every "interval" milliseconds, regardless of
how long the task takes.  If the task takes longer than the interval, it will
be scheduled at the next available multiple of interval.  For exmaple: If the
task has an interval of 60 secs and the task takes 70 secs (it better not),
the next invocation will happen at 120 seconds.

AST_SIP_SCHED_TASK_DELAY specifies that the next invocation of the task should
start "interval" milliseconds after the current invocation has finished.

Also, the same ast_sched facility for fixed or variable intervals exists.  The
task's return code in conjunction with the AST_SIP_SCHED_TASK_FIXED or
AST_SIP_SCHED_TASK_VARIABLE flags controls the next invocation start time.

One res_pjsip.h housekeeping change was made.  The pjsip header files were
added to the top.  There have been a few cases lately where I've needed
res_pjsip.h just for ast_sip calls and had compiles fail spectacularly because
I didn't add the pjsip header files to my source even though I never referenced
any pjsip calls.

Finally, a few new convenience APIs were added to astobj2 to make things a
little easier in the scheduler.  ao2_ref_and_lock() calls ao2_ref() and
ao2_lock() in one go.  ao2_unlock_and_unref() does the reverse. A few macros
were also copied from res_phoneprov because I got tired of having to duplicate
the same hash, sort and compare functions over and over again. The
AO2_STRING_FIELD_(HASH|SORT|CMP)_FN macros will insert functions suitable for
aor_container_alloc into your source.

This facility can be used immediately for the situations where we already have
a thread that wakes up periodically or do some scheduled work.  For the
registration and qualify issues, additional sorcery and schema changes would
need to be made so that we can easily detect changed objects on a periodic
basis without having to pull the entire database back to check.  I'm thinking
of a last-updated timestamp on the rows but more on this later.

Change-Id: I7af6ad2b2d896ea68e478aa1ae201d6dd016ba1c
---
M include/asterisk/astobj2.h
M include/asterisk/res_pjsip.h
M res/res_pjsip.c
M res/res_pjsip/include/res_pjsip_private.h
A res/res_pjsip/pjsip_scheduler.c
A tests/test_res_pjsip_scheduler.c
6 files changed, 1,291 insertions(+), 9 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/86/2486/6
-- 
To view, visit https://gerrit.asterisk.org/2486
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I7af6ad2b2d896ea68e478aa1ae201d6dd016ba1c
Gerrit-PatchSet: 6
Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Owner: George Joseph <george.joseph at fairview5.com>
Gerrit-Reviewer: Anonymous Coward #1000019
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Mark Michelson <mmichelson at digium.com>