[asterisk-dev] [Code Review] 4443: dial api: add self destruction option

[Scott Griepentrog]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4443/
-----------------------------------------------------------

(Updated Feb. 26, 2015, 12:53 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 432385


Repository: Asterisk


Description
-------

This adds a self-destruction ability to the dial api.  The usefulness of this is mostly when using async mode to spawn a separate thread to handle the new call, while the calling thread is allowed to go on about other business.  The alternative of this option is that the calling thread must either hang around for the duration or spawn it's own thread in order to create and then later destroy the dial structure after the call completes.

Example (minus error checking):

struct ast_dial *dial = ast_dial_create();

ast_dial_append(dial, "PJSIP", "200", NULL);

ast_dial_option_global_enable(dial, AST_DIAL_OPTION_ANSWER_EXEC, "Echo");
ast_dial_option_global_enable(dial, AST_DIAL_OPTION_SELF_DESTROY, NULL);

ast_dial_run(dial, NULL, 1);

The dial_run call returns almost immediately after spawning a new thread to complete and monitor the dial.  If the call is answered, it is put into echo.  When completed, ast_dial_destroy() will be called on the dial structure.

Note that any allocations made to pass values to ast_dial_set_user_data() or other dial options will need to be free'd in a state callback function on any of AST_DIAL_RESULT_UNASWERED, AST_DIAL_RESULT_ANSWERED, AST_DIAL_RESULT_HANGUP, or AST_DIAL_RESULT_TIMEOUT.


Diffs
-----

  /branches/13/main/dial.c 432173 
  /branches/13/include/asterisk/dial.h 432173 

Diff: https://reviewboard.asterisk.org/r/4443/diff/


Testing
-------

Correct operation confirmed with a temporary test function running under valgrind to insure there are no invalid references or leaks.


Thanks,

Scott Griepentrog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150226/1cbdd346/attachment.html>