Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Kea python hook? (Dave Cole)
2. Re: Kea python hook? (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Jan 2018 23:23:09 +0000
From: Dave Cole <[email protected]>
To: Francis Dupont <[email protected]>, David Hankins
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Kea python hook?
Message-ID:
<syxpr01mb17272457ce0123b20218dbd3f2...@syxpr01mb1727.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
I did not know that code existed!
I just had a quick look and you have done some interesting
things (compared to my code). I am not much of a C++ programmer
having last done it seriously back in 2000.
On big difference in approach is that the code you have created
will not work with current Kea if the Python code imports a
module with native code - unless you statically link your code
with Kea. Kea loads hooks with RTLD_LOCAL which prevents?symbols
in the hook being visible in subsequent dynamic linking. The
hook I created here connects to a database and publishes to Kafka
- we need to load native modules.
I implemented my hook as a two stage load. The Kea hook does
dlopen() on libpython, and then loads the kea native module and
bootstraps it via a Capsule. Implementing the kea native module
outside of kea means I can implement tests for my hook in Python
outside of kea.
One thing that concerned me when first looking at Kea was that
there did not seem to be any sensible way I could build unit
tests for my hook. Now I can use the full flexibility of Python
mocking and the unit test framework.
Another thing I am confused about in your code is that you do not
appear to do any exception handling. If Python code calls Kea
and an exception is raised, then the Python interpreter will get
corrupted.
From: Francis Dupont <[email protected]>
Sent: Saturday, 20 January 2018 7:24:03 PM
To: David Hankins
Cc: Dave Cole; [email protected]
Subject: Re: [kea-dev] Kea python hook?
?
About Kea hooks written in Python there was my old proof of concept in
the fdxhook branch available on github so it is feasible even not clearly
easier than to work directly in C++.
About managing leases from hooks there are current developments for
the High Availability. I am not sure they will help you...
I leave details to my colleagues.
Thanks
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Mon, 22 Jan 2018 09:09:48 +0000
From: Francis Dupont <[email protected]>
To: Dave Cole <[email protected]>
Cc: Francis Dupont <[email protected]>, David Hankins
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Kea python hook?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dave Cole writes:
> I did not know that code existed!
=> it had 2 purposes:
- show it is possible to write a hook in a script language vs requiring C++
with examples in Python, Lua, OCaml and v8
- detail technical points so someone who wants to do the same thing
can win a lot of time
> On big difference in approach is that the code you have created
> will not work with current Kea if the Python code imports a
> module with native code - unless you statically link your code
> with Kea. Kea loads hooks with RTLD_LOCAL which prevents symbols
> in the hook being visible in subsequent dynamic linking. The
> hook I created here connects to a database and publishes to Kafka
> - we need to load native modules.
=> currently hooks are dynamic shared objects which don't load
other DSOs and have no dependency between hooks, so RTLD_LOCAL
is enough. As it works for almost all cases and is simpler / faster
I believe it will stay the default but you can open a ticket asking
for a configure option to change it for RTLD_GLOBAL. If you provide
a pair of DSOs, one behaving as a hook and loading the second, for
unit tests, or pull a request on github, it will help because as
you know we have limited man power.
> Another thing I am confused about in your code is that you do not
> appear to do any exception handling. If Python code calls Kea
> and an exception is raised, then the Python interpreter will get
> corrupted.
=> I mention exceptions in the doc as one of the things which should
be implemented. Of course it is simpler if the C++ code called
from the external language does not raise exceptions (*) so
you don't have to add a handler to stop stack unwinding.
Thanks
Francis Dupont <[email protected]>
PS (*): C++ specs changed about possible exceptions declarations but
if you remove fatal errors like bad_alloc which can't be recovered
usually C++ code does not raise exceptions and this is a static
property (so the compiler can check it).
Kea code is supposed to have a doxygen documentation for all exported
methods or functions with parameters, result (if exists) and
possible exceptions. If you find a bug in that please signal it as
it will really be considered as a bug.
PPS: about C++11 noexcept: as we moved to C++11 we can use noexcept
in the code. I don't think there is already a policy, even for new code,
and I am sure that as even the question of adding or not noexcept is
clearly time consuming we do not plan to consider noexcept in short term.
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 46, Issue 2
**************************************
