19982013
Ericsson AB. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
The C Server Back-end
2004-01-14
C
ch_c_server.xml
Introduction
With the option {be, c_server} the IDL Compiler generates
C server skeletons according to the IDL to C mapping, on top of
the Erlang distribution and gen_server protocols.
The developer has to write additional code, that together with
the generated C server skeletons, form a hidden Erlang
node. That additional code contains implementations of call-back
functions that implement the true server functionality, and also
code uses erl_interface functions for defining the hidden
node and for establishing connections to other Erlang nodes.
Generated Stub Files
The generated stub files are:
-
For each IDL interface, a C source file, the name of which
is __s.c]]>. Each operation of the
IDL interface is mapped to a C function (with scoped name)
in that file;
-
C source files that contain functions for type conversion,
memory allocation, and data encoding/decoding;
-
C header files that contain function prototypes and type
definitions.
All C functions are exported (i.e. not declared static).
C Skeleton Functions
For each IDL operation a C skeleton function is generated, the
prototype of which is __exec( oe_obj, CORBA_Environment *oe_env)]]>, where ]]>, and
CORBA_Environment are of the same type as for the
generated C client stubs code.
Each __exec()]]> function calls the
call-back function
_rs* __cb( oe_obj, , CORBA_Environment *oe_env)]]>
where the arguments are of the same type as those generated for
C client stubs.
The return value _rs* ]]> is a pointer
to a function with the same signature as the call-back function
_cb]]>, and is called after the call-back
function has been evaluated (provided that the pointer is not equal
to NULL).
The Server Loop
The developer has to implement code for establishing connections
with other Erlang nodes, code for call-back functions and restore
functions.
In addition, the developer also has to implement code for a
server loop, that receives messages and calls the relevant
__exec function. For that purpose the IC library function
oe_server_receive() function can be used.
Generating, Compiling and Linking
To generate the C server skeletons type the following in an
appropriate shell:
erlc -I ICROOT/include "+{be, c_server}" File.idl,
where ICROOT is the root of the IC application. The
-I ICROOT/include is only needed if File.idl
refers to erlang.idl.
When compiling a generated C skeleton file, the directories
ICROOT/include and EICROOT/include, have to be
specified as include directories, where EIROOT is the
root directory of the Erl_interface application.
When linking object files the EIROOT/lib and
ICROOT/priv/lib directories have to be specified.
An Example
In this example the IDL specification file "random.idl" is used
for generating C server skeletons (the file is contained in the IC
/examples/c-server directory):
module rmod {
interface random {
double produce();
oneway void init(in long seed1, in long seed2, in long seed3);
};
};
Generate the C server skeletons:
erlc '+{be, c_server}' random.idl
Erlang IDL compiler version X.Y.Z
Six files are generated.
Compile the C server skeletons:
Please read the ReadMe file in the
examples/c-server directory.
In the same directory you can find all the code for this
example. In particular you will find the server.c file
that contains all the additional code that must be written to
obtain a complete server.
In the examples/c-server directory you will also find
source code for an Erlang client, which can be used for testing
the C server.