To be Reviewed By: Monday, 2020-04-13
Authors: Blake Bender
Status: Draft | Discussion | Development | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
...
- We will be adopting a specific naming convention for the C bindings to attempt to ensure unique names, since we can't take advantage of namespaces. Tentatively, we will prefix function names with `apache_geode_`, followed by 'Create' for methods that allocate a 'class instance', i.e. an opaque context pointer, and 'Destroy' for the dealloc/free function. For class methods, we will use 'apache_geode' + class name + '_' + method name. As a trivial example, a partial CacheFactory implementation with just new/delete and the method getVersion would be exported via C functions as follows:
- Since C functions can't be namespaced, we will adopt a naming convention for the C functions that distinguishes them as best they can be from application code. This will most likely be a string prefix representing the namespace, e.g. "apache_geode_client_CreateCacheFactory".
Code Block |
---|
apache_geode_CreateCacheFactory
apache_geode_CacheFactory_getVersion
apache_geode_DestroyCacheFactory |
Serialization
- Serialization in Geode is, of course, a large and complex topic. We do not, at the time of this writing, know all of the minute details of the ultimate implementation of serialization in any of the potential client languages which will use our C bindings. Generally, however, we plan to implement a mechanism sufficient to enable a client implementation of a PDX type handler and other necessary classes that matches the current C++/CLI implementation in geode-native.
Code Block |
---|
apache_geode_CreateCacheFactory
apache_geode_CacheFactory_getVersion
apache_geode_DestroyCacheFactory |
...
Performance Impact
Any performance impact of calling through a C binding should be very minimal. A C function exposing a native client method should only involve a pointer cast and a call to the "wrapped" C++ API. Additionally, there will be no performance impact whatsoever for existing applications, since we're not proposing to modify any of the existing C++ code. Eventually we should be able to benchmark the C vs C++ calls to quantify the performance difference, but this is a fairly low priority. Benchmarking API performance from another language calling through the C bindings is a much more interesting and necessary task, which we believe will be undertaken as part of any future support for said language.
...