[Asterisk-code-review] loader: Remove global symbol only startup phase. (asterisk[master])

[Richard Mudgett]

Richard Mudgett has posted comments on this change. ( https://gerrit.asterisk.org/7986 )

Change subject: loader: Remove global symbol only startup phase.
......................................................................


Patch Set 1:

> > (1 comment)
 > >
 > > > (1 comment)
 > > >
 > > > > (1 comment)
 > > > >
 > > > > I'm concerned that not having global symbol providers loaded
 > > > first
 > > > > will negatively impact OPTIONAL_API consumer modules.
 > > > >
 > > > > If a consumer of OPTIONAL_API functions is loaded before the
 > > > module
 > > > > that exports the OPTIONAL_API symbols then will the consumer
 > > > module
 > > > > only use the stub functions?
 > > >
 > > > In theory but that would require the consumer module to have
 > two
 > > > bugs: incorrect load_pri and lack of requires /
 > optional_modules
 > > > pointing to the provider module.
 > >
 > > You cannot know about the load_pri and requires/optional_modules
 > > lists until the actual module is loaded.  That information is
 > used
 > > to execute the module start functions in the correct order and
 > > cannot affect OPTIONAL_API linking.
 > >
 > > What I'm concerned with here is if the OPTIONAL_API consumer will
 > > call the real function or the stub if the module providing the
 > > OPTIONAL_API functions is loaded into memory AFTER the consumer
 > is
 > > loaded into memory.  This is a linking issue not a module start
 > > order issue.  The OPTIONAL_API behavior may even be platform
 > > dependent.
 > 
 > 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.
 > 
 > 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.

So is this new method used in the oldest OS's we support? CentOS, MacOS?


-- 
To view, visit https://gerrit.asterisk.org/7986
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I33e3174d67f3b4552d3d536326dcaf0ebabb097d
Gerrit-Change-Number: 7986
Gerrit-PatchSet: 1
Gerrit-Owner: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Wed, 17 Jan 2018 22:03:17 +0000
Gerrit-HasComments: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180117/3620b6d5/attachment.html>