1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
<TITLE>The C Server Back-end</TITLE>
<SCRIPT type="text/javascript" src="../../../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="8"><!-- Empty --></A>
<H2>8 The C Server Back-end</H2>
<A NAME="8.1"><!-- Empty --></A>
<H3>8.1 Introduction</H3>
<P> With the option <CODE>{be, c_server}</CODE> the IDL Compiler generates
C server skeletons according to the IDL to C mapping, on top of
the Erlang distribution and gen_server protocols.
<P> 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 <CODE>erl_interface</CODE> functions for defining the hidden
node and for establishing connections to other Erlang nodes.
<A NAME="8.2"><!-- Empty --></A>
<H3>8.2 Generated Stub Files</H3>
<P> The generated stub files are:
<P>
<UL>
<LI>
For each IDL interface, a C source file, the name of which
is <CODE><Scoped Interface Name>__s.c</CODE>. Each operation of the
IDL interface is mapped to a C function (with scoped name)
in that file;
<BR>
</LI>
<LI>
C source files that contain functions for type conversion,
memory allocation, and data encoding/decoding;
<BR>
</LI>
<LI>
C header files that contain function prototypes and type
definitions.
<BR>
</LI>
</UL>
<P> All C functions are exported (i.e. not declared static).
<A NAME="8.3"><!-- Empty --></A>
<H3>8.3 C Skeleton Functions</H3>
<P> For each IDL operation a C skeleton function is generated, the
prototype of which is <CODE>int <Scoped Function
Name>__exec(<Interface Object> oe_obj, CORBA_Environment
*oe_env)</CODE>, where <CODE><Interface Object></CODE>, and
<CODE>CORBA_Environment</CODE> are of the same type as for the
generated C client stubs code.
<P> Each <CODE><Scoped Function Name>__exec()</CODE> function calls the
call-back function
<P> <CODE><Scoped Function Name>_rs* <Scoped Function
Name>__cb(<Interface Object> oe_obj, <Parameters>,
CORBA_Environment *oe_env)</CODE>
<P> where the arguments are of the same type as those generated for
C client stubs.
<P> The return value <CODE><Scoped Function Name>_rs* </CODE> is a pointer
to a function with the same signature as the call-back function
<CODE><Scoped Function Name>_cb</CODE>, and is called after the call-back
function has been evaluated (provided that the pointer is not equal
to <CODE>NULL</CODE>).
<A NAME="8.4"><!-- Empty --></A>
<H3>8.4 The Server Loop</H3>
<P> The developer has to implement code for establishing connections
with other Erlang nodes, code for call-back functions and restore
functions.
<P>
<P> In addition, the developer also has to implement code for a
server loop, that receives messages and calls the relevant
<CODE>__exec</CODE> function. For that purpose the IC library function
<CODE>oe_server_receive()</CODE> function can be used.
<A NAME="8.5"><!-- Empty --></A>
<H3>8.5 Generating, Compiling and Linking</H3>
<P> To generate the C server skeletons type the following in an
appropriate shell:
<P>
<CODE>erlc -I ICROOT/include "+{be, c_server}" File.idl</CODE>,
<P> where <CODE>ICROOT</CODE> is the root of the IC application. The
<CODE>-I ICROOT/include</CODE> is only needed if <CODE>File.idl</CODE>
refers to <CODE>erlang.idl</CODE>.
<P> When compiling a generated C skeleton file, the directories
<CODE>ICROOT/include</CODE> and <CODE>EICROOT/include</CODE>, have to be
specified as include directories, where <CODE>EIROOT</CODE> is the
root directory of the Erl_interface application.
<P> When linking object files the <CODE>EIROOT/lib</CODE> and
<CODE>ICROOT/priv/lib</CODE> directories have to be specified.
<A NAME="8.6"><!-- Empty --></A>
<H3>8.6 An Example</H3>
<P> In this example the IDL specification file "random.idl" is used
for generating C server skeletons (the file is contained in the IC
<CODE>/examples/c-server</CODE> directory):
<PRE>
module rmod {
interface random {
double produce();
oneway void init(in long seed1, in long seed2, in long seed3);
};
};
</PRE>
<P>Generate the C server skeletons:
<PRE>
erlc '+{be, c_server}' random.idl
Erlang IDL compiler version X.Y.Z
</PRE>
<P> Six files are generated.
<P>Compile the C server skeletons:
<P> Please read the <CODE>ReadMe</CODE> file att the
<CODE>examples/c-server</CODE> directory.
<P> In the same directory you can find all the code for this
example. In particular you will find the <CODE>server.c</CODE> file
that contains all the additional code that must be written to
obtain a complete server.
<P> In the <CODE>examples/c-server</CODE> directory you will also find
source code for an Erlang client, which can be used for testing
the C server.
<CENTER>
<HR>
<SMALL>
Copyright © 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>
|
