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

[Corey Farrell]

Corey Farrell 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.


-- 
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 21:31:52 +0000
Gerrit-HasComments: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180117/29fbc119/attachment.html>