<p>Richard Mudgett <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;"><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>> > (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>><br>> In theory but that would require the consumer module to have<br>two<br>> bugs: incorrect load_pri and lack of requires /<br>optional_modules<br>> pointing to the provider module.<br>> You cannot know about the load_pri and requires/optional_modules<br>lists until the actual module is loaded. That information is<br>used<br>to execute the module start functions in the correct order and<br>cannot affect OPTIONAL_API linking.<br>> 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<br>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<br>in the day when OPTIONAL_API was implemented with weak symbols and<br>other advanced dynamic library stuff, that is no longer the case. <br>It is now implemented using generated __attribute__((constructor))<br>functions. The providers register an implementation for each<br>OPTIONAL_API function, the consumers register a pointer to it's own<br>static stub as well an address to store a pointer to either the<br>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<br>we dlopen res_ari first. Initially the stub functions will be<br>active, but as soon as we dlopen res_http_websocket the pointers in<br>res_ari will be switched from the stub to the real implementation. <br>The important thing is that this happen before res_ari is started<br>by the mod->load() callback, which it is. We do not need to<br>dlclose and reopen res_ari for this to happen.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">So is this new method used in the oldest OS's we support? CentOS, MacOS?</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 22:03:17 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>