[Asterisk-code-review] pbx: Ensure we don't operate on dialplan while dialplan is reloading, ... (asterisk[18])

[Mark Murawski]

Attention is currently required from: Sean Bright, Joshua Colp, Kevin Harwell.
Mark Murawski has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/17798 )

Change subject: pbx: Ensure we don't operate on dialplan while dialplan is reloading, which causes deadlocks
......................................................................


Patch Set 5:

(1 comment)

File pbx/pbx_config.c:

https://gerrit.asterisk.org/c/asterisk/+/17798/comment/44b5360e_8d8c76cd 
PS5, Line 2098: 	/*
> This will cause PBX execution to halt during the entire I/O and processing operation for extensions. […]
The reason for locking here, is that during pbx_load_config(), multiple calls to ast_add_extension2 are made without an overall lock, and other modules can squeek in and run ast_add_extension2 in the meantime while pbx_load_config() is running.

If there is an early-bail like the one I have in this patch for ast_add_extension2, then half the dialplan fails to load during a dialplan reload because other modules are interrupting and doing things like updating hints from sip and whatnot.

Locking PBX is good to know.  I was concerned about that but wasn't sure.  I know adding 'big locks' is the opposite direction of where things should go, but locking contexts while they are being written to en-masse did make sense at the time.

I think the right/next step here is going to be the reverse approach...  I think ast_add_extension needs to queue up changes and implement an 'added' callback.

For example extension_state_add_destroy() would need to be made to an async call to ast_add_extension with a registered completion callback because the assumption is that after the extension is added, we can use it.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/17798
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 18
Gerrit-Change-Id: I435db97fc56f18b6f5c25a3e400603817b07aa49
Gerrit-Change-Number: 17798
Gerrit-PatchSet: 5
Gerrit-Owner: Mark Murawski <markm at intellasoft.net>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-Reviewer: Sean Bright <sean at seanbright.com>
Gerrit-CC: Kevin Harwell <kharwell at digium.com>
Gerrit-Attention: Sean Bright <sean at seanbright.com>
Gerrit-Attention: Joshua Colp <jcolp at sangoma.com>
Gerrit-Attention: Kevin Harwell <kharwell at digium.com>
Gerrit-Comment-Date: Tue, 18 Jan 2022 13:32:08 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Joshua Colp <jcolp at sangoma.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220118/16b58238/attachment-0001.html>