diff options
Diffstat (limited to 'lib/erl_interface/doc/src/erl_interface.xml')
| -rw-r--r-- | lib/erl_interface/doc/src/erl_interface.xml | 198 |
1 files changed, 99 insertions, 99 deletions
diff --git a/lib/erl_interface/doc/src/erl_interface.xml b/lib/erl_interface/doc/src/erl_interface.xml index ab5b46cc01..4e66655b39 100644 --- a/lib/erl_interface/doc/src/erl_interface.xml +++ b/lib/erl_interface/doc/src/erl_interface.xml @@ -72,51 +72,51 @@ Eshell V4.7.4 (abort with ^G) 1> code:root_dir(). /usr/local/otp ]]></code> <p>To compile your code, make sure that your C compiler knows where - to find <c><![CDATA[erl_interface.h]]></c> by specifying an appropriate <c><![CDATA[-I]]></c> - argument on the command line, or by adding it to the <c><![CDATA[CFLAGS]]></c> - definition in your <c><![CDATA[Makefile]]></c>. The correct value for this path is - <c><![CDATA[$OTPROOT/lib/erl_interface]]></c><em>Vsn</em><c><![CDATA[/include]]></c>, where <c><![CDATA[$OTPROOT]]></c> is the path - reported by <c><![CDATA[code:root_dir/0]]></c> in the above example, and <em>Vsn</em> is + to find <c>erl_interface.h</c> by specifying an appropriate <c>-I</c> + argument on the command line, or by adding it to the <c>CFLAGS</c> + definition in your <c>Makefile</c>. The correct value for this path is + <c>$OTPROOT/lib/erl_interface</c><em>Vsn</em><c>/include</c>, where <c>$OTPROOT</c> is the path + reported by <c>code:root_dir/0</c> in the above example, and <em>Vsn</em> is the version of the Erl_interface application, for example - <c><![CDATA[erl_interface-3.2.3]]></c></p> + <c>erl_interface-3.2.3</c></p> <code type="none"><![CDATA[ $ cc -c -I/usr/local/otp/lib/erl_interface-3.2.3/include myprog.c ]]></code> <p>When linking, you will need to specify the path to - <c><![CDATA[liberl_interface.a]]></c> and <c><![CDATA[libei.a]]></c> with - <c><![CDATA[-L$OTPROOT/lib/erl_interface-3.2.3/lib]]></c>, and you will need to specify the - name of the libraries with <c><![CDATA[-lerl_interface -lei]]></c>. You can do - this on the command line or by adding the flags to the <c><![CDATA[LDFLAGS]]></c> - definition in your <c><![CDATA[Makefile]]></c>.</p> + <c>liberl_interface.a</c> and <c>libei.a</c> with + <c>-L$OTPROOT/lib/erl_interface-3.2.3/lib</c>, and you will need to specify the + name of the libraries with <c>-lerl_interface -lei</c>. You can do + this on the command line or by adding the flags to the <c>LDFLAGS</c> + definition in your <c>Makefile</c>.</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>Also, on some systems it may be necessary to link with some - additional libraries (e.g. <c><![CDATA[libnsl.a]]></c> and <c><![CDATA[libsocket.a]]></c> on - Solaris, or <c><![CDATA[wsock32.lib]]></c> on Windows) in order to use the + additional libraries (e.g. <c>libnsl.a</c> and <c>libsocket.a</c> on + Solaris, or <c>wsock32.lib</c> on Windows) in order to use the communication facilities of Erl_Interface.</p> <p>If you are using Erl_Interface functions in a threaded application based on POSIX threads or Solaris threads, then Erl_Interface needs access to some of the synchronization facilities in your threads package, and you will need to specify additional compiler flags in order to indicate which of the packages - you are using. Define <c><![CDATA[_REENTRANT]]></c> and either <c><![CDATA[STHREADS]]></c> or - <c><![CDATA[PTHREADS]]></c>. The default is to use POSIX threads if - <c><![CDATA[_REENTRANT]]></c> is specified.</p> + you are using. 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> <p>Note that both single threaded and default versions of the Erl_interface and Ei libraries are provided. (The single threaded versions are named - <c><![CDATA[liberl_interface_st]]></c> and <c><![CDATA[libei_st]]></c>). Whether the default + <c>liberl_interface_st</c> and <c>libei_st</c>). Whether the default versions of the libraries have support for threads or not is determined by if the platform in question has support for POSIX or Solaris threads. To check this, - have a look in the <c><![CDATA[eidefs.mk]]></c> file in the erl_interface src directory.</p> + have a look in the <c>eidefs.mk</c> file in the erl_interface src directory.</p> </section> <section> <title>Initializing the erl_interface Library</title> <p>Before calling any of the other Erl_Interface functions, you - must call <c><![CDATA[erl_init()]]></c> exactly once to initialize the library. - <c><![CDATA[erl_init()]]></c> takes two arguments, however the arguments are no + must call <c>erl_init()</c> exactly once to initialize the library. + <c>erl_init()</c> takes two arguments, however the arguments are no longer used by Erl_Interface, and should therefore be specified - as <c><![CDATA[erl_init(NULL,0)]]></c>.</p> + as <c>erl_init(NULL,0)</c>.</p> </section> <section> @@ -129,7 +129,7 @@ $ ld -L/usr/local/otp/lib/erl_interface-3.2.3/ number of C functions which create and manipulate Erlang data structures. The library also contains an encode and a decode function. The example below shows how to create and encode an Erlang tuple - <c><![CDATA[{tobbe,3928}]]></c>:</p> + <c>{tobbe,3928}</c>:</p> <code type="none"><![CDATA[ ETERM *arr[2], *tuple; @@ -140,26 +140,26 @@ 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><![CDATA[erl_send()]]></c> and - <c><![CDATA[erl_receive_msg]]></c>, which handle the encoding and decoding of + <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>Refer to the Reference Manual for a complete description of the following modules:</p> <list type="bulleted"> - <item>the <c><![CDATA[erl_eterm]]></c> module for creating Erlang terms</item> - <item>the <c><![CDATA[erl_marshal]]></c> module for encoding and decoding routines.</item> + <item>the <c>erl_eterm</c> module for creating Erlang terms</item> + <item>the <c>erl_marshal</c> module for encoding and decoding routines.</item> </list> </section> <section> <title>Building Terms and Patterns</title> <p>The previous example can be simplified by using - <c><![CDATA[erl_format()]]></c> to create an Erlang term.</p> + <c>erl_format()</c> to create an Erlang term.</p> <code type="none"><![CDATA[ ETERM *ep; ep = erl_format("{~a,~i}", "tobbe", 3928); ]]></code> - <p>Refer to the Reference Manual, the <c><![CDATA[erl_format]]></c> module, for a + <p>Refer to the Reference Manual, the <c>erl_format</c> module, for a full description of the different format directives. The following example is more complex:</p> <code type="none"><![CDATA[ @@ -172,9 +172,9 @@ ep = erl_format("[{name,~a},{age,~i},{data,~w}]", erl_free_compound(ep); ]]></code> <p>As in previous examples, it is your responsibility to free the memory allocated for Erlang terms. In this example, - <c><![CDATA[erl_free_compound()]]></c> ensures that the complete term pointed to - by <c><![CDATA[ep]]></c> is released. This is necessary, because the pointer from - the second call to <c><![CDATA[erl_format()]]></c> is lost. </p> + <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[ @@ -186,7 +186,7 @@ ep = erl_format("[{name,~a},{age,~i},{data,~w}]", 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><![CDATA[ep]]></c> and <c><![CDATA[ep2]]></c> is not important, + which you free the terms <c>ep</c> and <c>ep2</c> is not important, because the Erl_Interface library uses reference counting to determine when it is safe to actually remove objects. </p> <p>If you are not sure whether you have freed the terms properly, you @@ -204,14 +204,14 @@ printf("length of freelist: %ld\ /* really free the freelist */ erl_eterm_release(); ]]></code> - <p>Refer to the Reference Manual, the <c><![CDATA[erl_malloc]]></c> module for more + <p>Refer to the Reference Manual, the <c>erl_malloc</c> module for more information.</p> </section> <section> <title>Pattern Matching</title> <p>An Erlang pattern is a term that may contain unbound variables or - <c><![CDATA["do not care"]]></c> symbols. Such a pattern can be matched against a + <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> @@ -219,13 +219,13 @@ erl_eterm_release(); ETERM *pattern; pattern = erl_format("{madonna,Age,_}"); ]]></code> - <p><c><![CDATA[erl_match()]]></c> is used to perform pattern matching. It takes a + <p><c>erl_match()</c> is used to perform 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, we create a pattern with a variable <em>Age</em> which appears at two positions in the tuple. The pattern match is performed as follows:</p> <list type="ordered"> - <item><c><![CDATA[erl_match()]]></c> will bind the contents of + <item><c>erl_match()</c> will bind the contents of <em>Age</em> to <em>21</em> the first time it reaches the variable</item> <item>the second occurrence of <em>Age</em> will cause a test for equality between the terms since <em>Age</em> is already bound to @@ -248,14 +248,14 @@ if (erl_match(pattern, term)) { } erl_free_term(pattern); erl_free_term(term); ]]></code> - <p>Refer to the Reference Manual, the <c><![CDATA[erl_match()]]></c> function for + <p>Refer to the Reference Manual, the <c>erl_match()</c> function for more information.</p> </section> <section> <title>Connecting to a Distributed Erlang Node</title> <p>In order to connect to a distributed Erlang node you need to first - initialize the connection routine with <c><![CDATA[erl_connect_init()]]></c>, + initialize the connection routine with <c>erl_connect_init()</c>, which stores information such as the host name, node name, and IP address for later use:</p> <code type="none"><![CDATA[ @@ -263,9 +263,9 @@ int identification_number = 99; int creation=1; char *cookie="a secret cookie string"; /* An example */ erl_connect_init(identification_number, cookie, creation); ]]></code> - <p>Refer to the Reference Manual, the <c><![CDATA[erl_connect]]></c> module for more information.</p> + <p>Refer to the Reference Manual, the <c>erl_connect</c> module for more information.</p> <p>After initialization, you set up the connection to the Erlang node. - Use <c><![CDATA[erl_connect()]]></c> to specify the Erlang node you want to + Use <c>erl_connect()</c> to specify the Erlang node you want to connect to. The following example sets up the connection and should result in a valid socket file descriptor:</p> <code type="none"><![CDATA[ @@ -273,45 +273,45 @@ int sockfd; char *nodename="[email protected]"; /* An example */ if ((sockfd = erl_connect(nodename)) < 0) erl_err_quit("ERROR: erl_connect failed"); ]]></code> - <p><c><![CDATA[erl_err_quit()]]></c> prints the specified string and terminates - the program. Refer to the Reference Manual, the <c><![CDATA[erl_error()]]></c> + <p><c>erl_err_quit()</c> prints the specified string and terminates + the program. Refer to the Reference Manual, the <c>erl_error()</c> function for more information.</p> </section> <section> <title>Using EPMD</title> - <p><c><![CDATA[Epmd]]></c> is the Erlang Port Mapper Daemon. Distributed Erlang nodes - register with <c><![CDATA[epmd]]></c> on the localhost to indicate to other nodes that - they exist and can accept connections. <c><![CDATA[Epmd]]></c> maintains a register of + <p><c>Epmd</c> is the Erlang Port Mapper Daemon. Distributed Erlang nodes + register with <c>epmd</c> on the localhost 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><![CDATA[epmd]]></c> in order to find out the correct + another node, it first contacts <c>epmd</c> in order to find out the correct port number to connect to.</p> - <p>When you use <c><![CDATA[erl_connect()]]></c> to connect to an Erlang node, a - connection is first made to <c><![CDATA[epmd]]></c> and, if the node is known, a + <p>When you use <c>erl_connect()</c> 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><![CDATA[epmd]]></c> if they want other + <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><![CDATA[epmd]]></c>, you need to first create a listen socket + <p>Before registering with <c>epmd</c>, you need to 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><![CDATA[pub]]></c> is a file descriptor now connected to <c><![CDATA[epmd]]></c>. <c><![CDATA[Epmd]]></c> + <p><c>pub</c> is a file descriptor now connected to <c>epmd</c>. <c>Epmd</c> monitors the other end of the connection, and if it detects that the connection has been closed, the node will be unregistered. So, if you explicitly close the descriptor or if your node fails, it will be - unregistered from <c><![CDATA[epmd]]></c>.</p> + unregistered from <c>epmd</c>.</p> <p>Be aware that on some systems (such as VxWorks), a failed node will not be detected by this mechanism since 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><![CDATA[epmd]]></c> will prevent you from + failed. If a node has failed in this way, <c>epmd</c> will prevent you from registering a new node with the old name, since 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 will cause <c><![CDATA[epmd]]></c> to close the connection from the far end. Note + <p>This will cause <c>epmd</c> to close the connection from the far end. Note 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 may be consumed.</p> @@ -321,8 +321,8 @@ erl_unpublish(node); ]]></code> <title>Sending and Receiving Erlang Messages</title> <p>Use one of the following two functions to send messages:</p> <list type="bulleted"> - <item><c><![CDATA[erl_send()]]></c></item> - <item><c><![CDATA[erl_reg_send()]]></c></item> + <item><c>erl_send()</c></item> + <item><c>erl_reg_send()</c></item> </list> <p>As in Erlang, it is possible to send messages to a <em>Pid</em> or to a registered name. It is easier to send a @@ -330,17 +330,17 @@ erl_unpublish(node); ]]></code> a suitable <em>Pid</em>.</p> <p>Use one of the following two functions to receive messages:</p> <list type="bulleted"> - <item><c><![CDATA[erl_receive()]]></c></item> - <item><c><![CDATA[erl_receive_msg()]]></c></item> + <item><c>erl_receive()</c></item> + <item><c>erl_receive_msg()</c></item> </list> - <p><c><![CDATA[erl_receive()]]></c> receives the message into a buffer, while - <c><![CDATA[erl_receive_msg()]]></c> decodes the message into an Erlang term. </p> + <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><![CDATA[{Pid, hello_world}]]></c> is - sent to a registered process <c><![CDATA[my_server]]></c>. The message is encoded - by <c><![CDATA[erl_send()]]></c>:</p> + <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); @@ -355,15 +355,15 @@ 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 - <em>Pid</em>. This enables <c><![CDATA[my_server]]></c> to reply. Refer to the - Reference Manual, the <c><![CDATA[erl_connect]]></c> module for more information + <em>Pid</em>. This enables <c>my_server</c> to reply. Refer to the + Reference Manual, the <c>erl_connect</c> module for more information about send primitives.</p> </section> <section> <title>Example of Receiving Messages</title> - <p>In this example <c><![CDATA[{Pid, Something}]]></c> is received. The - received Pid is then used to return <c><![CDATA[{goodbye,Pid}]]></c></p> + <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; @@ -383,18 +383,18 @@ if ((rc = erl_receive_msg(sockfd , buf, BUFSIZE, &emsg)) == ERL_MSG) { <p>In order to provide robustness, a distributed Erlang node occasionally polls all its connected neighbours in an attempt to detect failed nodes or communication links. A node which receives such - a message is expected to respond immediately with an <c><![CDATA[ERL_TICK]]></c> message. - This is done automatically by <c><![CDATA[erl_receive()]]></c>, however when this - has occurred <c><![CDATA[erl_receive]]></c> returns <c><![CDATA[ERL_TICK]]></c> to the caller - without storing a message into the <c><![CDATA[ErlMessage]]></c> structure.</p> + 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><![CDATA[emsg.msg]]></c> as well as <c><![CDATA[emsg.to]]></c> - or <c><![CDATA[emsg.from]]></c>, depending on the type of message received.</p> + to free the received message <c>emsg.msg</c> as well as <c>emsg.to</c> + or <c>emsg.from</c>, depending on the type of message received.</p> <p>Refer to the Reference Manual for additional information about the following modules:</p> <list type="bulleted"> - <item><c><![CDATA[erl_connect]]></c></item> - <item><c><![CDATA[erl_eterm]]></c>.</item> + <item><c>erl_connect</c></item> + <item><c>erl_eterm</c>.</item> </list> </section> </section> @@ -421,12 +421,12 @@ if (!erl_match(ep, reply)) "); erl_free_term(ep); erl_free_term(reply); ]]></code> - <p><c><![CDATA[c:c/1]]></c> is called to compile the specified module on the - remote node. <c><![CDATA[erl_match()]]></c> checks that the compilation was - successful by testing for the expected <c><![CDATA[ok]]></c>.</p> - <p>Refer to the Reference Manual, the <c><![CDATA[erl_connect]]></c> module for - more information about <c><![CDATA[erl_rpc()]]></c>, and its companions - <c><![CDATA[erl_rpc_to()]]></c> and <c><![CDATA[erl_rpc_from()]]></c>.</p> + <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>Refer to the Reference Manual, the <c>erl_connect</c> module for + more information about <c>erl_rpc()</c>, and its companions + <c>erl_rpc_to()</c> and <c>erl_rpc_from()</c>.</p> </section> <section> @@ -454,14 +454,14 @@ if (names) ",names[i]); free(names); ]]></code> - <p><c><![CDATA[erl_global_names()]]></c> allocates and returns a buffer containing - all the names known to global. <c><![CDATA[count]]></c> will be initialized to + <p><c>erl_global_names()</c> allocates and returns a buffer containing + all the names known to global. <c>count</c> will be initialized to indicate how many names are in the array. The array of strings in names is terminated by a NULL pointer, so it is not necessary to use - <c><![CDATA[count]]></c> to determine when the last name is reached.</p> + <c>count</c> to determine when the last name is reached.</p> <p>It is the caller's responsibility to free the array. - <c><![CDATA[erl_global_names()]]></c> allocates the array and all of the strings - using a single call to <c><![CDATA[malloc()]]></c>, so <c><![CDATA[free(names)]]></c> is all + <c>erl_global_names()</c> allocates the array and all of 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[ @@ -469,13 +469,13 @@ ETERM *pid; char node[256]; pid = erl_global_whereis(fd,"schedule",node); ]]></code> - <p>If <c><![CDATA["schedule"]]></c> is known to global, an Erlang pid is returned + <p>If <c>"schedule"</c> is known to global, an Erlang pid is returned that can be used to send messages to the schedule service. - Additionally, <c><![CDATA[node]]></c> will be initialized to contain the name of + Additionally, <c>node</c> will be 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 <c><![CDATA[erl_connect()]]></c>.</p> + connection to it by simply passing the variable to <c>erl_connect()</c>.</p> <p>Before registering a name, you should already have registered your - port number with <c><![CDATA[epmd]]></c>. This is not strictly necessary, but if you + 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 will be unable to find or connect to your process.</p> <p>Create a pid that Erlang processes can use to communicate with your @@ -485,9 +485,9 @@ ETERM *pid; pid = erl_mk_pid(thisnode,14,0,0); erl_global_register(fd,servicename,pid); ]]></code> - <p>After registering the name, you should use <c><![CDATA[erl_accept()]]></c> to wait for + <p>After registering the name, you should use <c>erl_accept()</c> to wait for incoming connections.</p> - <p>Do not forget to free <c><![CDATA[pid]]></c> later with <c><![CDATA[erl_free_term()]]></c>!</p> + <p>Do not forget to free <c>pid</c> later with <c>erl_free_term()</c>!</p> <p>To unregister a name:</p> <code type="none"><![CDATA[ erl_global_unregister(fd,servicename); ]]></code> @@ -570,12 +570,12 @@ ei_reg_close(reg); ]]></code> <title>Backing Up the Registry to Mnesia</title> <p>The contents of a registry can be backed up to Mnesia on a "nearby" Erlang node. You need to provide an open connection to the Erlang node - (see <c><![CDATA[erl_connect()]]></c>). Also, Mnesia 3.0 or later must be running + (see <c>erl_connect()</c>). Also, Mnesia 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>The example above will backup the contents of the registry to the - specified Mnesia table <c><![CDATA["mtab"]]></c>. Once a registry has been backed + specified Mnesia table <c>"mtab"</c>. Once a registry has been backed up to Mnesia in this manner, additional backups will only affect objects that have been modified since the most recent backup, i.e. objects that have been created, changed or deleted. The backup @@ -584,7 +584,7 @@ ei_reg_dump(fd, reg, "mtab", dumpflags); ]]></code> <p>In the same manner, a registry can be restored from a Mnesia table:</p> <code type="none"><![CDATA[ ei_reg_restore(fd, reg, "mtab"); ]]></code> - <p>This will read the entire contents of <c><![CDATA["mtab"]]></c> into the specified + <p>This will read the entire contents of <c>"mtab"</c> into the specified registry. After the restore, all of the objects in the registry will be marked as unmodified, so a subsequent backup will only affect objects that you have modified since the restore.</p> @@ -600,8 +600,8 @@ ei_reg_restore(fd, reg, "mtab"); ]]></code> <p>When string or binary objects are stored in the registry it is important that a number of simple guidelines are followed. </p> <p>Most importantly, the object must have been created with a single call - to <c><![CDATA[malloc()]]></c> (or similar), so that it can later be removed by a - single call to <c><![CDATA[free()]]></c>. Objects will be freed by the registry + to <c>malloc()</c> (or similar), so that it can later be removed by a + single call to <c>free()</c>. Objects will be 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>You should also be aware that if you store binary objects that are @@ -618,8 +618,8 @@ ei_reg_restore(fd, reg, "mtab"); ]]></code> you make, possibly causing it to be missed the next time you make a Mnesia backup of the registry contents. This can be avoided if you mark the object as dirty after any such changes with - <c><![CDATA[ei_reg_markdirty()]]></c>, or pass appropriate flags to - <c><![CDATA[ei_reg_dump()]]></c>.</p> + <c>ei_reg_markdirty()</c>, or pass appropriate flags to + <c>ei_reg_dump()</c>.</p> </section> </section> </chapter> |