<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">It sounds like we should move forward with Francis' implementation as a baseline?  I'll take a stab at using it.  What would it take to convince ISC to merge it into master?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">It would be simplest in our deployment environment to configure Kea to find and use a python module we provide than to build a custom hook.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 1:09 AM, Francis Dupont <span dir="ltr"><<a href="mailto:fdupont@isc.org" target="_blank">fdupont@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Dave Cole writes:<br>
> I did not know that code existed!<br>
<br>
</span>=> it had 2 purposes:<br>
 - show it is possible to write a hook in a script language vs requiring C++<br>
  with examples in Python, Lua, OCaml and v8<br>
<br>
 - detail technical points so someone who wants to do the same thing<br>
  can win a lot of time<br>
<span class=""><br>
> On big difference in approach is that the code you have created<br>
> will not work with current Kea if the Python code imports a<br>
> module with native code - unless you statically link your code<br>
> with Kea.  Kea loads hooks with RTLD_LOCAL which prevents symbols<br>
> in the hook being visible in subsequent dynamic linking.  The<br>
> hook I created here connects to a database and publishes to Kafka<br>
> - we need to load native modules.<br>
<br>
</span>=> currently hooks are dynamic shared objects which don't load<br>
other DSOs and have no dependency between hooks, so RTLD_LOCAL<br>
is enough. As it works for almost all cases and is simpler / faster<br>
I believe it will stay the default but you can open a ticket asking<br>
for a configure option to change it for RTLD_GLOBAL. If you provide<br>
a pair of DSOs, one behaving as a hook and loading the second, for<br>
unit tests, or pull a request on github, it will help because as<br>
you know we have limited man power.<br>
<span class=""><br>
> Another thing I am confused about in your code is that you do not<br>
> appear to do any exception handling.  If Python code calls Kea<br>
> and an exception is raised, then the Python interpreter will get<br>
> corrupted.<br>
<br>
</span>=> I mention exceptions in the doc as one of the things which should<br>
be implemented. Of course it is simpler if the C++ code called<br>
from the external language does not raise exceptions (*) so<br>
you don't have to add a handler to stop stack unwinding.<br>
<br>
Thanks<br>
<br>
Francis Dupont <<a href="mailto:fdupont@isc.org">fdupont@isc.org</a>><br>
<br>
PS (*): C++ specs changed about possible exceptions declarations but<br>
if you remove fatal errors like bad_alloc which can't be recovered<br>
usually C++ code does not raise exceptions and this is a static<br>
property (so the compiler can check it).<br>
Kea code is supposed to have a doxygen documentation for all exported<br>
methods or functions with parameters, result (if exists) and<br>
possible exceptions. If you find a bug in that please signal it as<br>
it will really be considered as a bug.<br>
PPS: about C++11 noexcept: as we moved to C++11 we can use noexcept<br>
in the code. I don't think there is already a policy, even for new code,<br>
and I am sure that as even the question of adding or not noexcept is<br>
clearly time consuming we do not plan to consider noexcept in short term.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><font face="monospace, monospace">Infrastructure Management Services</font></div><div><font face="monospace, monospace">Twitter, Inc.</font></div></div></div></div></div></div></div>
</div>