<p>Corey Farrell <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/7986">View Change</a></p><p>Patch set 1:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">(1 comment)</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">(1 comment)<br>> > (1 comment)<br>><br>> I'm concerned that not having global symbol providers loaded<br>first<br>> will negatively impact OPTIONAL_API consumer modules.<br>><br>> If a consumer of OPTIONAL_API functions is loaded before the<br>module<br>> that exports the OPTIONAL_API symbols then will the consumer<br>module<br>> only use the stub functions?<br>> In theory but that would require the consumer module to have two<br>bugs: incorrect load_pri and lack of requires / optional_modules<br>pointing to the provider module.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">You cannot know about the load_pri and requires/optional_modules<br>lists until the actual module is loaded.  That information is used<br>to execute the module start functions in the correct order and<br>cannot affect OPTIONAL_API linking.</p><p style="white-space: pre-wrap; word-wrap: break-word;">What I'm concerned with here is if the OPTIONAL_API consumer will<br>call the real function or the stub if the module providing the<br>OPTIONAL_API functions is loaded into memory AFTER the consumer is<br>loaded into memory.  This is a linking issue not a module start<br>order issue.  The OPTIONAL_API behavior may even be platform<br>dependent.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Ah now I understand your concern.  This may have been the case back in the day when OPTIONAL_API was implemented with weak symbols and other advanced dynamic library stuff, that is no longer the case.  It is now implemented using generated __attribute__((constructor)) functions.  The providers register an implementation for each OPTIONAL_API function, the consumers register a pointer to it's own static stub as well an address to store a pointer to either the real function or the stub.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Take res_http_websocket and res_ari for example.  It's 100% OK if we dlopen res_ari first.  Initially the stub functions will be active, but as soon as we dlopen res_http_websocket the pointers in res_ari will be switched from the stub to the real implementation.  The important thing is that this happen before res_ari is started by the mod->load() callback, which it is.  We do not need to dlclose and reopen res_ari for this to happen.</p><ul style="list-style: none; padding-left: 20px;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/7986">change 7986</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/7986"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I33e3174d67f3b4552d3d536326dcaf0ebabb097d </div>
<div style="display:none"> Gerrit-Change-Number: 7986 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Wed, 17 Jan 2018 21:31:52 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>