aboutsummaryrefslogtreecommitdiffstats
path: root/lib/erl_interface/doc/src/ei_users_guide.xml
blob: 7ca10d1a9978a222e6ce2ea71b1fcb499178c1ae (plain) (blame)
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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2002</year><year>2016</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      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.

    </legalnotice>

    <title>Erl_Interface User's Guide</title>
    <prepared>Kent Boortz</prepared>
    <responsible>Kent Boortz</responsible>
    <docno></docno>
    <approved></approved>
    <checked></checked>
    <date></date>
    <rev></rev>
    <file>ei_users_guide.xml</file>
  </header>

  <section>
    <title>Deprecation and Removal</title>
    <note><p>The support for VxWorks is deprecated as of OTP 22, and
    will be removed in OTP 23.</p></note>
    <note><p>The old legacy <c>erl_interface</c> library (functions
    with prefix <c>erl_</c>) is deprecated as of OTP 22, and will be
    removed in OTP 23. This does not apply to the <c>ei</c>
    library. Reasonably new <c>gcc</c> compilers will issue deprecation
    warnings. In order to disable these warnings, define the macro
    <c>EI_NO_DEPR_WARN</c>.</p></note>
  </section>

  <section>
    <title>Introduction</title>
    <p>The <c>Erl_Interface</c> library contains functions that help you
      integrate programs written in C and Erlang. The functions in
      <c>Erl_Interface</c> support the following:</p>
    <list type="bulleted">
      <item>Manipulation of data represented as Erlang data types</item>
      <item>Conversion of data between C and Erlang formats</item>
      <item>Encoding and decoding of Erlang data types for transmission or
        storage</item>
      <item>Communication between C nodes and Erlang processes</item>
      <item>Backup and restore of C node state to and from
        <seealso marker="mnesia:mnesia">Mnesia</seealso></item>
    </list>
    <note>
      <p>By default, the <c>Erl_Interface</c> libraries are only guaranteed
        to be compatible with other Erlang/OTP components from the same
        release as the libraries themselves. For information about how to
        communicate with Erlang/OTP components from earlier releases, see
        function <seealso marker="ei#ei_set_compat_rel">
        <c>ei:ei_set_compat_rel</c></seealso> and
        <seealso marker="erl_eterm#erl_set_compat_rel">
        <c>erl_eterm:erl_set_compat_rel</c></seealso>.</p>
    </note>

    <section>
      <title>Scope</title>
      <p>In the following sections, these topics are described:</p>
      <list type="bulleted">
        <item>Compiling your code for use with <c>Erl_Interface</c></item>
        <item>Initializing <c>Erl_Interface</c></item>
        <item>Encoding, decoding, and sending Erlang terms</item>
        <item>Building terms and patterns</item>
        <item>Pattern matching</item>
        <item>Connecting to a distributed Erlang node</item>
        <item>Using the Erlang Port Mapper Daemon (EPMD)</item>
        <item>Sending and receiving Erlang messages</item>
        <item>Remote procedure calls</item>
        <item>Using global names</item>
        <item>Using the registry</item>
      </list>
    </section>

    <section>
      <title>Prerequisites</title>
      <p>It is assumed that the reader is familiar with the Erlang programming
        language.</p>
    </section>
  </section>

  <section>
    <title>Compiling and Linking Your Code</title>
    <p>To use any of the <c>Erl_Interface</c> functions, include the
      following lines in your code:</p>

    <code type="none"><![CDATA[
#include "erl_interface.h"
#include "ei.h"    ]]></code>

    <p>Determine where the top directory of your OTP installation is.
      To find this, start Erlang and enter the following
      command at the Eshell prompt:</p>

    <code type="none"><![CDATA[
Eshell V4.7.4  (abort with ^G)
1> code:root_dir().
/usr/local/otp    ]]></code>

    <p>To compile your code, ensure that your C compiler knows where
      to find <c>erl_interface.h</c> by specifying an appropriate
      <c>-I</c> argument on the command line, or add it to
      the <c>CFLAGS</c> definition in your
      <c>Makefile</c>. The correct value for this path is
      <c>$OTPROOT/lib/erl_interface-$EIVSN/include</c>,
      where:</p>

    <list type="bulleted">
      <item>
        <p><c>$OTPROOT</c> is the path reported by
          <c>code:root_dir/0</c> in the example above.</p>
      </item>
      <item>
        <p><c>$EIVSN</c> is the version of the <c>Erl_Interface</c> application,
          for example, <c>erl_interface-3.2.3</c>.</p>
      </item>
    </list>

    <p>Compiling the code:</p>

    <code type="none"><![CDATA[
$ cc -c -I/usr/local/otp/lib/erl_interface-3.2.3/include myprog.c    ]]></code>

    <p>When linking:</p>

    <list type="bulleted">
      <item>Specify the path to <c>liberl_interface.a</c> and
        <c>libei.a</c> with
        <c>-L$OTPROOT/lib/erl_interface-3.2.3/lib</c>.</item>
      <item>Specify the name of the libraries with
        <c>-lerl_interface -lei</c>.</item>
    </list>

    <p>Do this on the command line or add the flags to the
      <c>LDFLAGS</c> definition in your
      <c>Makefile</c>.</p>

    <p>Linking the code:</p>

    <code type="none"><![CDATA[
$ ld -L/usr/local/otp/lib/erl_interface-3.2.3/
                            lib myprog.o -lerl_interface -lei -o myprog    ]]></code>

    <p>On some systems it can be necessary to link with some more
      libraries (for example, <c>libnsl.a</c> and
      <c>libsocket.a</c> on Solaris, or
      <c>wsock32.lib</c> on Windows) to use the
      communication facilities of <c>Erl_Interface</c>.</p>

    <p>If you use the <c>Erl_Interface</c> functions in a threaded
      application based on POSIX threads or Solaris threads, then
      <c>Erl_Interface</c> needs access to some of the synchronization
      facilities in your threads package. You must specify extra
      compiler flags to indicate which of the packages you use. Define
      <c>_REENTRANT</c> and either <c>STHREADS</c> or
      <c>PTHREADS</c>. The default is to use POSIX threads if
      <c>_REENTRANT</c> is specified.</p>
  </section>

  <section>
    <title>Initializing the Libraries</title>
    <p>
      Before calling any of the other functions in the <c>erl_interface</c>
      and <c>ei</c> libraries, call <c>erl_init()</c> exactly once to initialize
      both libraries.
      <c>erl_init()</c> takes two arguments. However, the arguments
      are no longer used by <c>erl_interface</c> and are therefore to be
      specified as <c>erl_init(NULL,0)</c>.
    </p>
    <p>
      If you only use the <c>ei</c> library, instead initialize it by calling
      <c>ei_init()</c> exactly once before calling any other functions in
      the <c>ei</c> library.
    </p>
  </section>

  <section>
    <title>Encoding, Decoding, and Sending Erlang Terms</title>
    <p>Data sent between distributed Erlang nodes is encoded in the
      Erlang external format. You must therefore encode and decode
      Erlang terms into byte streams if you want to use the distribution
      protocol to communicate between a C program and Erlang.</p>

    <p>The <c>Erl_Interface</c> library supports this activity. It has
      several C functions that create and manipulate Erlang data
      structures. The library also contains an encode and a decode function.
      The following example shows how to create and encode an Erlang tuple
      <c>{tobbe,3928}</c>:</p>

    <code type="none"><![CDATA[
ETERM *arr[2], *tuple;
char buf[BUFSIZ];
int i;
  
arr[0] = erl_mk_atom("tobbe");
arr[1] = erl_mk_integer(3928);
tuple  = erl_mk_tuple(arr, 2);
i = erl_encode(tuple, buf);    ]]></code>

    <p>Alternatively, you can use <c>erl_send()</c> and
      <c>erl_receive_msg</c>, which handle the encoding and
      decoding of messages transparently.</p>

    <p>For a complete description, see the following modules:</p>
    <list type="bulleted">
      <item><seealso marker="erl_eterm"><c>erl_eterm</c></seealso>
        for creating Erlang terms</item>
      <item><seealso marker="erl_marshal"><c>erl_marshal</c></seealso>
        for encoding and decoding routines</item>
    </list>
  </section>

  <section>
    <marker id="building_terms_and_patterns"/>
    <title>Building Terms and Patterns</title>
    <p>The previous example can be simplified by using the
      <seealso marker="erl_format"><c>erl_format</c></seealso> module
      to create an Erlang term:</p>

    <code type="none"><![CDATA[
ETERM *ep;
ep = erl_format("{~a,~i}", "tobbe", 3928);    ]]></code>

    <p>For a complete description of the different format directives, see
      the <seealso marker="erl_format"><c>erl_format</c></seealso> module.</p>

    <p>The following example is more complex:</p>

    <code type="none"><![CDATA[
ETERM *ep;
ep = erl_format("[{name,~a},{age,~i},{data,~w}]",
                 "madonna", 
                 21, 
                 erl_format("[{adr,~s,~i}]", "E-street", 42));
erl_free_compound(ep);      ]]></code>

    <p>As in the previous examples, it is your responsibility to free the
      memory allocated for Erlang terms. In this example,
      <c>erl_free_compound()</c> ensures that the complete term
      pointed to by <c>ep</c> is released. This is necessary
      because the pointer from the second call to <c>erl_format</c> is lost.</p>

    <p>The following example shows a slightly different solution:</p>

    <code type="none"><![CDATA[
ETERM *ep,*ep2;
ep2 = erl_format("[{adr,~s,~i}]","E-street",42);
ep  = erl_format("[{name,~a},{age,~i},{data,~w}]",
                 "madonna", 21, ep2);
erl_free_term(ep);  
erl_free_term(ep2);      ]]></code>

    <p>In this case, you free the two terms independently. The order in
      which you free the terms <c>ep</c> and <c>ep2</c>
      is not important,
      because the <c>Erl_Interface</c> library uses reference counting to
      determine when it is safe to remove objects.</p>

    <p>If you are unsure whether you have freed the terms properly, you
      can use the following function to see the status of the fixed term
      allocator:</p>

    <code type="none"><![CDATA[
long allocated, freed;

erl_eterm_statistics(&allocated,&freed);
printf("currently allocated blocks: %ld\n",allocated);
printf("length of freelist: %ld\n",freed);

/* really free the freelist */
erl_eterm_release();
    ]]></code>

    <p>For more information, see the
      <seealso marker="erl_malloc"><c>erl_malloc</c></seealso> module.</p>
  </section>

  <section>
    <title>Pattern Matching</title>
    <p>An Erlang pattern is a term that can contain unbound variables or
      <c>"do not care"</c> symbols. Such a pattern can be matched
      against a
      term and, if the match is successful, any unbound variables in the
      pattern will be bound as a side effect. The content of a bound
      variable can then be retrieved:</p>

    <code type="none"><![CDATA[
ETERM *pattern;
pattern = erl_format("{madonna,Age,_}");    ]]></code>

    <p>The <seealso marker="erl_format#erl_match">
      <c>erl_format:erl_match</c></seealso> function
      performs pattern matching. It takes a
      pattern and a term and tries to match them. As a side effect any unbound
      variables in the pattern will be bound. In the following example, a
      pattern is created with a variable <c>Age</c>, which is included at two
      positions in the tuple. The pattern match is performed as follows:</p>

    <list type="bulleted">
      <item>
        <p><c>erl_match</c> binds the contents of <c>Age</c> to <c>21</c>
          the first time it reaches the variable.</p>
      </item>
      <item>
        <p>The second occurrence of <c>Age</c> causes a test for
          equality between the terms, as <c>Age</c> is already bound to
          <c>21</c>. As <c>Age</c> is bound to <c>21</c>, the equality test
          succeeds and the match continues until the end of the pattern.</p>
      </item>
      <item>
        <p>If the end of the pattern is reached, the match succeeds and you
          can retrieve the contents of the variable.</p>
      </item>
    </list>

    <code type="none"><![CDATA[
ETERM *pattern,*term;
pattern = erl_format("{madonna,Age,Age}");
term    = erl_format("{madonna,21,21}");
if (erl_match(pattern, term)) {
  fprintf(stderr, "Yes, they matched: Age = ");
  ep = erl_var_content(pattern, "Age"); 
  erl_print_term(stderr, ep);
  fprintf(stderr,"\n");
  erl_free_term(ep);
}
erl_free_term(pattern);
erl_free_term(term);    ]]></code>

    <p>For more information, see the
      <seealso marker="erl_format#erl_match">
      <c>erl_format:erl_match</c></seealso> function.</p>
  </section>

  <section>
    <title>Connecting to a Distributed Erlang Node</title>
    <p>To connect to a distributed Erlang node, you must first
      initialize the connection routine with
      <seealso marker="erl_connect#erl_connect_init">
      <c>erl_connect:erl_connect_init</c></seealso>,
      which stores information, such as the hostname, node name, and IP
      address for later use:</p>

    <code type="none"><![CDATA[
int identification_number = 99;
int creation=1;
char *cookie="a secret cookie string"; /* An example */
erl_connect_init(identification_number, cookie, creation);    ]]></code>

    <p>For more information, see the
      <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>

    <p>After initialization, you set up the connection to the Erlang node.
      To specify the Erlang node you want to connect to, use
      <c>erl_connect()</c>. The following example sets up the
      connection and is to result in a valid socket file descriptor:</p>

    <code type="none"><![CDATA[
int sockfd;
char *nodename="[email protected]"; /* An example */
if ((sockfd = erl_connect(nodename)) < 0)
  erl_err_quit("ERROR: erl_connect failed");    ]]></code>

    <p><c>erl_err_quit()</c> prints the specified string and
      terminates the program. For more information, see the
      <seealso marker="erl_error"><c>erl_error</c></seealso> module.</p>
  </section>

  <section>
    <title>Using EPMD</title>
    <p><seealso marker="erts:epmd"><c>erts:epmd</c></seealso>
      is the Erlang Port Mapper Daemon. Distributed
      Erlang nodes register with <c>epmd</c> on the local host to
      indicate to other nodes that they exist and can accept connections.
      <c>epmd</c> maintains a register of
      node and port number information, and when a node wishes to connect to
      another node, it first contacts <c>epmd</c> to find the
      correct port number to connect to.</p>

    <p>When you use
      <seealso marker="erl_connect"><c>erl_connect</c></seealso>
      to connect to an Erlang node, a connection is first made to
      <c>epmd</c> and, if the node is known, a
      connection is then made to the Erlang node.</p>

    <p>C nodes can also register themselves with <c>epmd</c>
      if they want other
      nodes in the system to be able to find and connect to them.</p>

    <p>Before registering with <c>epmd</c>, you must first
      create a listen socket and bind it to a port. Then:</p>

    <code type="none"><![CDATA[
int pub;

pub = erl_publish(port);    ]]></code>

    <p><c>pub</c> is a file descriptor now connected to
      <c>epmd</c>. <c>epmd</c>
      monitors the other end of the connection. If it detects that the
      connection has been closed, the node becomes unregistered. So, if you
      explicitly close the descriptor or if your node fails, it becomes
      unregistered from <c>epmd</c>.</p>

    <p>Notice that on some systems (such as VxWorks), a failed node is
      not detected by this mechanism, as the operating system does not
      automatically close descriptors that were left open when the node
      failed. If a node has failed in this way, <c>epmd</c>
      prevents you from
      registering a new node with the old name, as it thinks that the old
      name is still in use. In this case, you must unregister the name
      explicitly:</p>

    <code type="none"><![CDATA[
erl_unpublish(node);    ]]></code>

    <p>This causes <c>epmd</c> to close the connection from the
      far end. Notice
      that if the name was in fact still in use by a node, the results of
      this operation are unpredictable. Also, doing this does not cause the
      local end of the connection to close, so resources can be consumed.</p>
  </section>

  <section>
    <title>Sending and Receiving Erlang Messages</title>
    <p>Use one of the following two functions to send messages:</p>

    <list type="bulleted">
      <item><seealso marker="erl_connect#erl_send">
        <c>erl_connect:erl_send</c></seealso></item>
      <item><seealso marker="erl_connect#erl_reg_send">
        <c>erl_connect:erl_reg_send</c></seealso></item>
    </list>

    <p>As in Erlang, messages can be sent to a
      pid or to a registered name. It is easier to send a
      message to a registered name, as it avoids the problem of finding
      a suitable pid.</p>

    <p>Use one of the following two functions to receive messages:</p>

    <list type="bulleted">
      <item><seealso marker="erl_connect#erl_receive">
        <c>erl_connect:erl_receive</c></seealso></item>
      <item><seealso marker="erl_connect#erl_receive_msg">
        <c>erl_connect:erl_receive_msg</c></seealso></item>
    </list>

    <p><c>erl_receive()</c> receives the message into a buffer,
      while <c>erl_receive_msg()</c> decodes the message into an
      Erlang term.</p>

    <section>
      <title>Example of Sending Messages</title>
      <p>In the following example, <c>{Pid, hello_world}</c> is
        sent to a registered process <c>my_server</c>. The message
        is encoded by <c>erl_send()</c>:</p>

      <code type="none"><![CDATA[
extern const char *erl_thisnodename(void);
extern short erl_thiscreation(void);
#define SELF(fd) erl_mk_pid(erl_thisnodename(),fd,0,erl_thiscreation())
ETERM *arr[2], *emsg;
int sockfd, creation=1;
  
arr[0] = SELF(sockfd);
arr[1] = erl_mk_atom("Hello world");
emsg   = erl_mk_tuple(arr, 2);
  
erl_reg_send(sockfd, "my_server", emsg);
erl_free_term(emsg);      ]]></code>

      <p>The first element of the tuple that is sent is your own
        pid. This enables <c>my_server</c> to reply.
        For more information about the primitives, see the
        <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>
    </section>

    <section>
      <title>Example of Receiving Messages</title>
      <p>In this example, <c>{Pid, Something}</c> is received. The
        received pid is then used to return
        <c>{goodbye,Pid}</c>.</p>

      <code type="none"><![CDATA[
ETERM *arr[2], *answer;
int sockfd,rc;
char buf[BUFSIZE];
ErlMessage emsg;
  
if ((rc = erl_receive_msg(sockfd , buf, BUFSIZE, &emsg)) == ERL_MSG) {
   arr[0] = erl_mk_atom("goodbye");
   arr[1] = erl_element(1, emsg.msg); 
   answer = erl_mk_tuple(arr, 2);
   erl_send(sockfd, arr[1], answer);
   erl_free_term(answer);
   erl_free_term(emsg.msg);
   erl_free_term(emsg.to);
}      ]]></code>

      <p>To provide robustness, a distributed Erlang node
        occasionally polls all its connected neighbors in an attempt to
        detect failed nodes or communication links. A node that receives such
        a message is expected to respond immediately with an
        <c>ERL_TICK</c> message. This is done automatically by
        <c>erl_receive()</c>. However, when this has occurred,
        <c>erl_receive</c> returns <c>ERL_TICK</c> to
        the caller without storing a message into the
        <c>ErlMessage</c> structure.</p>

      <p>When a message has been received, it is the caller's responsibility
        to free the received message <c>emsg.msg</c> and
        <c>emsg.to</c> or <c>emsg.from</c>,
        depending on the type of message received.</p>

      <p>For more information, see the
        <seealso marker="erl_connect"><c>erl_connect</c></seealso> and
        <seealso marker="erl_eterm"><c>erl_eterm</c></seealso> modules.</p>
    </section>
  </section>

  <section>
    <title>Remote Procedure Calls</title>
    <p>An Erlang node acting as a client to another Erlang node
      typically sends a request and waits for a reply. Such a request is
      included in a function call at a remote node and is called a remote
      procedure call.</p>

    <p>The following example shows how the
      <c>Erl_Interface</c> library supports remote procedure calls:</p>

    <code type="none"><![CDATA[
char modname[]=THE_MODNAME;
ETERM *reply,*ep;
ep = erl_format("[~a,[]]", modname);
if (!(reply = erl_rpc(fd, "c", "c", ep)))
  erl_err_msg("<ERROR> when compiling file: %s.erl !\n", modname);
erl_free_term(ep);
ep = erl_format("{ok,_}");
if (!erl_match(ep, reply))
  erl_err_msg("<ERROR> compiler errors !\n");
erl_free_term(ep);
erl_free_term(reply);    ]]></code>

    <p><c>c:c/1</c> is called to compile the specified module on
      the remote node. <c>erl_match()</c> checks that the
      compilation was
      successful by testing for the expected <c>ok</c>.</p>

    <p>For more information about <c>erl_rpc()</c> and its
      companions <c>erl_rpc_to()</c> and
      <c>erl_rpc_from()</c>, see the
      <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>
  </section>

  <section>
    <title>Using Global Names</title>
    <p>A C node has access to names registered through the
      <seealso marker="kernel:global"><c>global</c></seealso>
      module in Kernel. Names can be looked up, allowing the C node to send messages
      to named Erlang services. C nodes can also register global names,
      allowing them to provide named services to Erlang processes or other C
      nodes.</p>

    <p><c>Erl_Interface</c> does not provide a native implementation of the
      global service. Instead it uses the global services provided by a "nearby"
      Erlang node. To use the services described in this section,
      it is necessary to first open a connection to an Erlang node.</p>

    <p>To see what names there are:</p>

    <code type="none"><![CDATA[
char **names;
int count;
int i;

names = erl_global_names(fd,&count);

if (names) 
  for (i=0; i<count; i++) 
    printf("%s\n",names[i]);

free(names);    ]]></code>

    <p><seealso marker="erl_global#erl_global_names">
      <c>erl_global:erl_global_names</c></seealso>
      allocates and returns a buffer containing
      all the names known to the <c>global</c> module in <c>Kernel</c>.
      <c>count</c> is initialized to
      indicate the number of names in the array. The array of strings in names
      is terminated by a <c>NULL</c> pointer, so it is not necessary to use
      <c>count</c> to determine when the last name is reached.</p>

    <p>It is the caller's responsibility to free the array.
      <c>erl_global_names</c> allocates the array and all the strings
      using a single call to <c>malloc()</c>, so
      <c>free(names)</c> is all that is necessary.</p>

    <p>To look up one of the names:</p>

    <code type="none"><![CDATA[
ETERM *pid;
char node[256];

pid = erl_global_whereis(fd,"schedule",node);    ]]></code>

    <p>If <c>"schedule"</c> is known to the
      <c>global</c> module in <c>Kernel</c>, an Erlang pid is
      returned that can be used to send messages to the schedule service.
      Also, <c>node</c> is initialized to contain the name of
      the node where the service is registered, so that you can make a
      connection to it by simply passing the variable to
      <seealso marker="erl_connect"><c>erl_connect</c></seealso>.</p>

    <p>Before registering a name, you should already have registered your
      port number with <c>epmd</c>. This is not strictly necessary,
      but if you
      neglect to do so, then other nodes wishing to communicate with your
      service cannot find or connect to your process.</p>

    <p>Create a pid that Erlang processes can use to communicate with your
      service:</p>

    <code type="none"><![CDATA[
ETERM *pid;

pid = erl_mk_pid(thisnode,14,0,0);
erl_global_register(fd,servicename,pid);    ]]></code>

    <p>After registering the name, use
        <seealso marker="erl_connect#erl_accept">
        <c>erl_connect:erl_accept</c></seealso>
        to wait for incoming connections.</p>

    <note>
      <p>Remember to free <c>pid</c> later with
        <seealso marker="erl_malloc#erl_free_term">
        <c>erl_malloc:erl_free_term</c></seealso>.</p>
    </note>

    <p>To unregister a name:</p>

    <code type="none"><![CDATA[
erl_global_unregister(fd,servicename);    ]]></code>
  </section>

  <section>
    <title>Using the Registry</title>
    <p>This section describes the use of the registry, a simple mechanism
      for storing key-value pairs in a C-node, as well as backing them up or
      restoring them from an <c>Mnesia</c> table on an Erlang node. For more
      detailed information about the individual API functions, see the
      <seealso marker="registry"><c>registry</c></seealso> module.</p>

   <p>Keys are strings, that is, <c>NULL</c>-terminated arrays of characters, and
      values are arbitrary objects. Although integers and floating point numbers
      are treated specially by the registry, you can store strings or binary
      objects of any type as pointers.</p>

    <p>To start, open a registry:</p>

    <code type="none"><![CDATA[
ei_reg *reg;

reg = ei_reg_open(45);    ]]></code>

    <p>The number <c>45</c> in the example indicates the approximate number of
      objects that you expect to store in the registry. Internally the
      registry uses hash tables with collision chaining, so there is no
      absolute upper limit on the number of objects that the registry can
      contain, but if performance or memory usage is important, then you
      are to choose a number accordingly. The registry can be resized later.</p>

    <p>You can open as many registries as you like (if memory permits).</p>

    <p>Objects are stored and retrieved through set and get functions.
      The following example shows how to store integers, floats, strings,
      and arbitrary binary objects:</p>

    <code type="none"><![CDATA[
struct bonk *b = malloc(sizeof(*b));
char *name = malloc(7);

ei_reg_setival(reg,"age",29); 
ei_reg_setfval(reg,"height",1.85);

strcpy(name,"Martin");
ei_reg_setsval(reg,"name",name); 

b->l = 42;
b->m = 12;
ei_reg_setpval(reg,"jox",b,sizeof(*b));    ]]></code>

    <p>If you try to store an object in the registry and there is an
      existing object with the same key, the new value replaces the old
      one. This is done regardless of whether the new object and the old one
      have the same type, so you can, for example, replace a string with an
      integer. If the existing value is a string or binary, it is freed
      before the new value is assigned.</p>

    <p>Stored values are retrieved from the registry as follows:</p>

    <code type="none"><![CDATA[
long i;
double f;
char *s;
struct bonk *b;
int size;

i = ei_reg_getival(reg,"age");
f = ei_reg_getfval(reg,"height");
s = ei_reg_getsval(reg,"name");
b = ei_reg_getpval(reg,"jox",&size);    ]]></code>

    <p>In all the above examples, the object must exist and it must be of
      the right type for the specified operation. If you do not know the
      type of an object, you can ask:</p>

    <code type="none"><![CDATA[
struct ei_reg_stat buf;

ei_reg_stat(reg,"name",&buf);    ]]></code>

    <p>Buf is initialized to contain object attributes.</p>

    <p>Objects can be removed from the registry:</p>

    <code type="none"><![CDATA[
ei_reg_delete(reg,"name");    ]]></code>

    <p>When you are finished with a registry, close it to remove all the
      objects and free the memory back to the system:</p>

    <code type="none"><![CDATA[
ei_reg_close(reg);    ]]></code>

    <section>
      <title>Backing Up the Registry to Mnesia</title>
      <p>The contents of a registry can be backed up to
        <seealso marker="mnesia:mnesia"><c>Mnesia</c></seealso> on a "nearby" Erlang
        node. You must provide an open connection to the Erlang node
        (see <seealso marker="erl_connect"><c>erl_connect</c></seealso>).
        Also, <c>Mnesia</c> 3.0 or later must be running
        on the Erlang node before the backup is initiated:</p>

      <code type="none"><![CDATA[
ei_reg_dump(fd, reg, "mtab", dumpflags);      ]]></code>

      <p>This example back up the contents of the registry to the
        specified <c>Mnesia</c> table <c>"mtab"</c>.
        Once a registry has been backed
        up to <c>Mnesia</c> like this, more backups only affect
        objects that have been modified since the most recent backup, that is,
        objects that have been created, changed, or deleted. The backup
        operation is done as a single atomic transaction, so that either the
        entire backup is performed or none of it.</p>

      <p>Likewise, a registry can be restored from a <c>Mnesia</c> table:</p>

      <code type="none"><![CDATA[
ei_reg_restore(fd, reg, "mtab");      ]]></code>

      <p>This reads the entire contents of <c>"mtab"</c> into the
        specified registry. After the restore, all the objects in the registry
        are marked as unmodified, so a later backup only affects
        objects that you have modified since the restore.</p>

      <p>Notice that if you restore to a non-empty registry, objects in the
        table overwrite objects in the registry with the same keys. Also,
        the <em>entire</em> contents of the registry is marked as unmodified
        after the restore, including any modified objects that were not
        overwritten by the restore operation. This may not be your
        intention.</p>
    </section>

    <section>
      <title>Storing Strings and Binaries</title>
      <p>When string or binary objects are stored in the registry it is
        important that some simple guidelines are followed.</p>

      <p>Most importantly, the object must have been created with a single call
        to <c>malloc()</c> (or similar), so that it can later be
        removed by a single call to <c>free()</c>.
        Objects are freed by the registry
        when it is closed, or when you assign a new value to an object that
        previously contained a string or binary.</p>

      <p>Notice that if you store binary objects that are context-dependent
        (for example, containing pointers or open file descriptors),
        they lose their meaning if they are backed up to a <c>Mnesia</c> table
        and later restored in a different context.</p>

      <p>When you retrieve a stored string or binary value from the registry,
        the registry maintains a pointer to the object and you are passed a
        copy of that pointer. You should never free an object retrieved in
        this manner because when the registry later attempts to free it, a
        runtime error occurs that likely causes the C-node to crash.</p>

      <p>You are free to modify the contents of an object retrieved this way.
        However, when you do so, the registry is not aware of your changes,
        possibly causing it to be missed the next time you make an
        <c>Mnesia</c> backup of the registry contents. This can be avoided if
        you mark the object as dirty after any such changes with
        <seealso marker="registry#ei_reg_markdirty">
        <c>registry:ei_reg_markdirty</c></seealso>, or pass appropriate flags to
        <seealso marker="registry#ei_reg_dump">
        <c>registry:ei_reg_dump</c></seealso>.</p>
    </section>
  </section>
</chapter>