aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--erts/doc/src/driver.xml39
-rw-r--r--erts/doc/src/erl_driver.xml94
-rw-r--r--erts/epmd/src/epmd.c2
-rw-r--r--erts/etc/win32/erlsrv/erlsrv_service.c4
-rw-r--r--erts/example/next_perm.cc2
-rw-r--r--lib/kernel/doc/src/inet.xml2
-rw-r--r--lib/stdlib/doc/src/binary.xml2
-rw-r--r--lib/stdlib/doc/src/zip.xml20
-rw-r--r--system/doc/efficiency_guide/advanced.xml2
-rw-r--r--system/doc/efficiency_guide/binaryhandling.xml6
-rw-r--r--system/doc/efficiency_guide/drivers.xml2
-rw-r--r--system/doc/efficiency_guide/functions.xml2
-rw-r--r--system/doc/efficiency_guide/processes.xml8
-rw-r--r--system/doc/efficiency_guide/profiling.xml16
-rw-r--r--system/doc/efficiency_guide/tablesDatabases.xml6
15 files changed, 100 insertions, 107 deletions
diff --git a/erts/doc/src/driver.xml b/erts/doc/src/driver.xml
index db455312ec..2b1ed398ee 100644
--- a/erts/doc/src/driver.xml
+++ b/erts/doc/src/driver.xml
@@ -63,7 +63,8 @@
<p>This is a simple driver for accessing a postgres
database using the libpq C client library. Postgres
is used because it's free and open source. For information
- on postgres, refer to the website www.postgres.org.</p>
+ on postgres, refer to the website
+ <url href="http://www.postgres.org">www.postgres.org</url>.</p>
<p>The driver is synchronous, it uses the synchronous calls of
the client library. This is only for simplicity, and is
generally not good, since it will
@@ -210,7 +211,7 @@ static void stop(ErlDrvData drv_data)
input data is a string paramater for <c><![CDATA[connect]]></c> and
<c><![CDATA[select]]></c>. The returned data consists of Erlang terms.</p>
<p>The functions <c><![CDATA[get_s]]></c> and <c><![CDATA[ei_x_to_new_binary]]></c> are
- utilities that is used to make the code shorter. <c><![CDATA[get_s]]></c>
+ utilities that are used to make the code shorter. <c><![CDATA[get_s]]></c>
duplicates the string and zero-terminates it, since the
postgres client library wants that. <c><![CDATA[ei_x_to_new_binary]]></c>
takes an <c><![CDATA[ei_x_buff]]></c> buffer and allocates a binary and
@@ -244,7 +245,7 @@ static int control(ErlDrvData drv_data, unsigned int command, char *buf,
return r;
}
]]></code>
- <p>In <c><![CDATA[do_connect]]></c> is where we log in to the database. If the connection
+ <p><c><![CDATA[do_connect]]></c> is where we log in to the database. If the connection
was successful we store the connection handle in our driver
data, and return ok. Otherwise, we return the error message
from postgres, and store <c><![CDATA[NULL]]></c> in the driver data.</p>
@@ -264,7 +265,7 @@ static int do_connect(const char *s, our_data_t* data, ei_x_buff* x)
}
]]></code>
<p>If we are connected (if the connection handle is not <c><![CDATA[NULL]]></c>),
- we log out from the database. We need to check if a we should
+ we log out from the database. We need to check if we should
encode an ok, since we might get here from the <c><![CDATA[stop]]></c>
function, which doesn't return data to the emulator.</p>
<code type="none"><![CDATA[
@@ -279,7 +280,7 @@ static int do_disconnect(our_data_t* data, ei_x_buff* x)
return 0;
}
]]></code>
- <p>We execute a query and encodes the result. Encoding is done
+ <p>We execute a query and encode the result. Encoding is done
in another C module, <c><![CDATA[pg_encode.c]]></c> which is also provided
as sample code.</p>
<code type="none"><![CDATA[
@@ -291,7 +292,7 @@ static int do_select(const char* s, our_data_t* data, ei_x_buff* x)
return 0;
}
]]></code>
- <p>Here we simply checks the result from postgres, and
+ <p>Here we simply check the result from postgres, and
if it's data we encode it as lists of lists with
column data. Everything from postgres is C strings,
so we just use <c><![CDATA[ei_x_encode_string]]></c> to send
@@ -392,7 +393,7 @@ disconnect(Port) ->
select(Port, Query) ->
binary_to_term(port_control(Port, ?DRV_SELECT, Query)).
]]></code>
- <p>The api is simple: <c><![CDATA[connect/1]]></c> loads the driver, opens it
+ <p>The API is simple: <c><![CDATA[connect/1]]></c> loads the driver, opens it
and logs on to the database, returning the Erlang port
if successful, <c><![CDATA[select/2]]></c> sends a query to the driver,
and returns the result, <c><![CDATA[disconnect/1]]></c> closes the
@@ -417,7 +418,7 @@ select(Port, Query) ->
<p>Sometimes database queries can take long time to
complete, in our <c><![CDATA[pg_sync]]></c> driver, the emulator
halts while the driver is doing its job. This is
- often not acceptable, since no other Erlang processes
+ often not acceptable, since no other Erlang process
gets a chance to do anything. To improve on our
postgres driver, we reimplement it using the asynchronous
calls in LibPQ.</p>
@@ -472,7 +473,7 @@ typedef struct our_data_t {
whether the driver is waiting for a connection or waiting
for the result of a query. (This is needed since the entry
<c><![CDATA[ready_io]]></c> will be called both when connecting and
- when there is query result.)</p>
+ when there is a query result.)</p>
<code type="none"><![CDATA[
static int do_connect(const char *s, our_data_t* data)
{
@@ -571,7 +572,7 @@ static void ready_io(ErlDrvData drv_data, ErlDrvEvent event)
connection is successful, or error if it's not. If the
connection is not yet established, we simply return; <c><![CDATA[ready_io]]></c>
will be called again.</p>
- <p>If we have result from a connect, indicated that we have data in
+ <p>If we have a result from a connect, indicated by having data in
the <c><![CDATA[x]]></c> buffer, we no longer need to select on
output (<c><![CDATA[ready_output]]></c>), so we remove this by calling
<c><![CDATA[driver_select]]></c>.</p>
@@ -630,9 +631,9 @@ return_port_data(Port) ->
message queue. The function <c><![CDATA[return_port_data]]></c> above
receives data from the port. Since the data is in
binary format, we use <c><![CDATA[binary_to_term/1]]></c> to convert
- it to Erlang term. Note that the driver is opened in
- binary mode, <c><![CDATA[open_port/2]]></c> is called with the option
- <c><![CDATA[[binary]]]></c>. This means that data sent from the driver
+ it to an Erlang term. Note that the driver is opened in
+ binary mode (<c><![CDATA[open_port/2]]></c> is called with the option
+ <c><![CDATA[[binary]]]></c>). This means that data sent from the driver
to the emulator is sent as binaries. Without the <c><![CDATA[binary]]></c>
option, they would have been lists of integers.</p>
</section>
@@ -646,15 +647,15 @@ return_port_data(Port) ->
of a list of integers. For large lists (more than 100000
elements), this will take some time, so we will perform this
as an asynchronous task.</p>
- <p>The asynchronous api for drivers are quite complicated. First
+ <p>The asynchronous API for drivers is quite complicated. First
of all, the work must be prepared. In our example we do this
in <c><![CDATA[output]]></c>. We could have used <c><![CDATA[control]]></c> just as well,
but we want some variation in our examples. In our driver, we allocate
- a structure that contains all needed for the asynchronous task
+ a structure that contains anything that's needed for the asynchronous task
to do the work. This is done in the main emulator thread.
Then the asynchronous function is called from a driver thread,
- separate from the main emulator thread. Note that the driver-
- functions are not reentrant, so they shouldn't be used.
+ separate from the main emulator thread. Note that the driver-functions
+ are not reentrant, so they shouldn't be used.
Finally, after the function is completed, the driver callback
<c><![CDATA[ready_async]]></c> is called from the main emulator thread,
this is where we return the result to Erlang. (We can't
@@ -692,7 +693,7 @@ static ErlDrvEntry next_perm_driver_entry = {
be sent later from the <c><![CDATA[ready_async]]></c> call-back.</p>
<p>The <c><![CDATA[async_data]]></c> will be passed to the <c><![CDATA[do_perm]]></c> function.
We do not use a <c><![CDATA[async_free]]></c> function (the last argument to
- <c><![CDATA[driver_async]]></c>, it's only used if the task is cancelled
+ <c><![CDATA[driver_async]]></c>), it's only used if the task is cancelled
programmatically.</p>
<code type="none"><![CDATA[
struct our_async_data {
@@ -743,7 +744,7 @@ static void ready_async(ErlDrvData drv_data, ErlDrvThreadData async_data)
ErlDrvPort port = reinterpret_cast<ErlDrvPort>(drv_data);
our_async_data* d = reinterpret_cast<our_async_data*>(async_data);
int n = d->data.size(), result_n = n*2 + 3;
- ErlDrvTermData* result = new ErlDrvTermData[result_n], * rp = result;
+ ErlDrvTermData *result = new ErlDrvTermData[result_n], *rp = result;
for (vector<int>::iterator i = d->data.begin();
i != d->data.end(); ++i) {
*rp++ = ERL_DRV_INT;
diff --git a/erts/doc/src/erl_driver.xml b/erts/doc/src/erl_driver.xml
index 497a2fa01d..066a2a4b92 100644
--- a/erts/doc/src/erl_driver.xml
+++ b/erts/doc/src/erl_driver.xml
@@ -56,16 +56,16 @@
instance is connected to an Erlang port. Every port has a port
owner process. Communication with the port is normally done
through the port owner process.</p>
- <p>Most of the functions takes the <c>port</c> handle as an
+ <p>Most of the functions take the <c>port</c> handle as an
argument. This identifies the driver instance. Note that this
port handle must be stored by the driver, it is not given when
the driver is called from the emulator (see
<seealso marker="driver_entry#emulator">driver_entry</seealso>).</p>
- <p>Some of the functions takes a parameter of type
+ <p>Some of the functions take a parameter of type
<c>ErlDrvBinary</c>, a driver binary. It should be both
- allocated and freed by the caller. Using a binary directly avoid
+ allocated and freed by the caller. Using a binary directly avoids
one extra copying of data.</p>
- <p>Many of the output functions has a "header buffer", with
+ <p>Many of the output functions have a "header buffer", with
<c>hbuf</c> and <c>hlen</c> parameters. This buffer is sent as a
list before the binary (or list, depending on port mode) that is
sent. This is convenient when matching on messages received from
@@ -92,7 +92,7 @@
with SMP support without being rewritten if driver
level locking is used.</p>
<note>
- <p>It is assumed that drivers does not access other drivers. If
+ <p>It is assumed that drivers do not access other drivers. If
drivers should access each other they have to provide their own
mechanism for thread safe synchronization. Such "inter driver
communication" is strongly discouraged.</p>
@@ -113,12 +113,12 @@
call-backs may be made from different threads.</p>
</note>
<p>Most functions in this API are <em>not</em> thread-safe, i.e.,
- they may <em>not</em> be called from an arbitrary thread. Function
+ they may <em>not</em> be called from an arbitrary thread. Functions
that are not documented as thread-safe may only be called from
driver call-backs or function calls descending from a driver
call-back call. Note that driver call-backs may be called from
different threads. This, however, is not a problem for any
- functions in this API, since the emulator have control over
+ function in this API, since the emulator has control over
these threads.</p>
<note>
<p>Functions not explicitly documented as thread-safe are
@@ -155,10 +155,10 @@
more information.</p>
</item>
<tag>Output functions</tag>
- <item>With the output functions, the driver sends data back
+ <item>With the output functions, the driver sends data back to
the emulator. They will be received as messages by the port owner
process, see <c>open_port/2</c>. The vector function and the
- function taking a driver binary is faster, because that avoid
+ function taking a driver binary are faster, because they avoid
copying the data buffer. There is also a fast way of sending
terms from the driver, without going through the binary term
format.</item>
@@ -193,14 +193,14 @@
use functionality from the POSIX thread API or the Windows
native thread API.
</p>
- <p>The Erlang driver thread API only return error codes when it is
+ <p>The Erlang driver thread API only returns error codes when it is
reasonable to recover from an error condition. If it isn't reasonable
to recover from an error condition, the whole runtime system is
terminated. For example, if a create mutex operation fails, an error
code is returned, but if a lock operation on a mutex fails, the
whole runtime system is terminated.
</p>
- <p>Note that there exist no "condition variable wait with timeout" in
+ <p>Note that there exists no "condition variable wait with timeout" in
the Erlang driver thread API. This is due to issues with
<c>pthread_cond_timedwait()</c>. When the system clock suddenly
is changed, it isn't always guaranteed that you will wake up from
@@ -241,7 +241,7 @@
to give you better error reports.
</p>
</item>
- <tag>Adding / remove drivers</tag>
+ <tag>Adding / removing drivers</tag>
<item>A driver can add and later remove drivers.</item>
<tag>Monitoring processes</tag>
<item>A driver can monitor a process that does not own a port.</item>
@@ -262,7 +262,7 @@
could, under rare circumstances, mean that drivers have to
be slightly modified. If so, this will of course be documented.
<c>ERL_DRV_EXTENDED_MINOR_VERSION</c> will be incremented when
- new features are added. The runtime system use the minor version
+ new features are added. The runtime system uses the minor version
of the driver to determine what features to use.
The runtime system will refuse to load a driver if the major
versions differ, or if the major versions are equal and the
@@ -273,7 +273,7 @@
It can, however, not make sure that it isn't incompatible. Therefore,
when loading a driver that doesn't use the extended driver
interface, there is a risk that it will be loaded also when
- the driver is incompatible. When the driver use the extended driver
+ the driver is incompatible. When the driver uses the extended driver
interface, the emulator can verify that it isn't of an incompatible
driver version. You are therefore advised to use the extended driver
interface.</p>
@@ -309,7 +309,7 @@ typedef struct ErlDrvSysInfo {
<seealso marker="#driver_system_info">driver_system_info()</seealso>
will write the system information when passed a reference to
a <c>ErlDrvSysInfo</c> structure. A description of the
- fields in the structure follow:
+ fields in the structure follows:
</p>
<taglist>
<tag><c>driver_major_version</c></tag>
@@ -347,14 +347,6 @@ typedef struct ErlDrvSysInfo {
<item>A value <c>!= 0</c> if the runtime system has SMP support;
otherwise, <c>0</c>.
</item>
- <tag><c>thread_support</c></tag>
- <item>A value <c>!= 0</c> if the runtime system has thread support;
- otherwise, <c>0</c>.
- </item>
- <tag><c>smp_support</c></tag>
- <item>A value <c>!= 0</c> if the runtime system has SMP support;
- otherwise, <c>0</c>.
- </item>
<tag><c>async_threads</c></tag>
<item>The number of async threads in the async thread pool used
by <seealso marker="#driver_async">driver_async()</seealso>
@@ -401,8 +393,8 @@ typedef struct ErlDrvBinary {
<seealso marker="#driver_binary_dec_refc">driver_binary_dec_refc()</seealso>.</p>
</note>
<p>Some driver calls, such as <c>driver_enq_binary</c>,
- increments the driver reference count, and others, such as
- <c>driver_deq</c> decrements it.</p>
+ increment the driver reference count, and others, such as
+ <c>driver_deq</c> decrement it.</p>
<p>Using a driver binary instead of a normal buffer, is often
faster, since the emulator doesn't need to copy the data,
only the pointer is used.</p>
@@ -415,7 +407,7 @@ typedef struct ErlDrvBinary {
<c>driver_outputv</c> calls, and in the queue. Also the
driver call-back <seealso marker="driver_entry#outputv">outputv</seealso> uses driver
binaries.</p>
- <p>If the driver of some reason or another, wants to keep a
+ <p>If the driver for some reason or another, wants to keep a
driver binary around, in a static variable for instance, the
reference count should be incremented,
and the binary can later be freed in the <seealso marker="driver_entry#stop">stop</seealso> call-back, with
@@ -423,7 +415,7 @@ typedef struct ErlDrvBinary {
<p>Note that since a driver binary is shared by the driver and
the emulator, a binary received from the emulator or sent to
the emulator, must not be changed by the driver.</p>
- <p>From erts version 5.5 (OTP release R11B), orig_bytes is
+ <p>Since erts version 5.5 (OTP release R11B), orig_bytes is
guaranteed to be properly aligned for storage of an array of
doubles (usually 8-byte aligned).</p>
</item>
@@ -447,7 +439,7 @@ typedef struct ErlIOVec {
int vsize;
int size;
SysIOVec* iov;
- >ErlDrvBinary** binv;
+ ErlDrvBinary** binv;
} ErlIOVec;
</code>
<p>The I/O vector used by the emulator and drivers, is a list
@@ -495,17 +487,17 @@ typedef struct ErlIOVec {
Currently, the only port specific data that the emulator
associates with the port data lock is the driver queue.</p>
<p>Normally a driver instance does not have a port data lock. If
- the driver instance want to use a port data lock, it has to
+ the driver instance wants to use a port data lock, it has to
create the port data lock by calling
<seealso marker="#driver_pdl_create">driver_pdl_create()</seealso>.
<em>NOTE</em>: Once the port data lock has been created, every
- access to data associated with the port data lock have to be done
+ access to data associated with the port data lock has to be done
while having the port data lock locked. The port data lock is
locked, and unlocked, respectively, by use of
<seealso marker="#driver_pdl_lock">driver_pdl_lock()</seealso>, and
<seealso marker="#driver_pdl_unlock">driver_pdl_unlock()</seealso>.</p>
<p>A port data lock is reference counted, and when the reference
- count reach zero, it will be destroyed. The emulator will at
+ count reaches zero, it will be destroyed. The emulator will at
least increment the reference count once when the lock is
created and decrement it once when the port associated with
the lock terminates. The emulator will also increment the
@@ -545,7 +537,7 @@ typedef struct ErlIOVec {
</p>
<taglist>
<tag>suggested_stack_size</tag>
- <item>A suggestion, in kilo-words, on how large stack to use. A value less
+ <item>A suggestion, in kilo-words, on how large a stack to use. A value less
than zero means default size.
</item>
</taglist>
@@ -648,7 +640,7 @@ typedef struct ErlIOVec {
opened.</p>
<p>The data is queued in the port owner process' message
queue. Note that this does not yield to the emulator. (Since
- the driver and the emulator runs in the same thread.)</p>
+ the driver and the emulator run in the same thread.)</p>
<p>The parameter <c>buf</c> points to the data to send, and
<c>len</c> is the number of bytes.</p>
<p>The return value for all output functions is 0. (Unless the
@@ -749,7 +741,7 @@ typedef struct ErlIOVec {
function <seealso marker="driver_entry#emulator">timeout</seealso> is called.</p>
<p>Note that there is only one timer on each driver instance;
setting a new timer will replace an older one.</p>
- <p>Return value i 0 (-1 only when the <c>timeout</c> driver
+ <p>Return value is 0 (-1 only when the <c>timeout</c> driver
function is <c>NULL</c>).</p>
</desc>
</func>
@@ -799,20 +791,20 @@ typedef struct ErlIOVec {
event object must be a socket or pipe (or other object that
<c>select</c>/<c>poll</c> can use).
On windows, the Win32 API function <c>WaitForMultipleObjects</c>
- is used. This places other restriction on the event object.
+ is used. This places other restrictions on the event object.
Refer to the Win32 SDK documentation.</p>
<p>The <c>on</c> parameter should be <c>1</c> for setting events
and <c>0</c> for clearing them.</p>
- <p>The <c>mode</c> argument is bitwise-or combination of
+ <p>The <c>mode</c> argument is a bitwise-or combination of
<c>ERL_DRV_READ</c>, <c>ERL_DRV_WRITE</c> and <c>ERL_DRV_USE</c>.
- The first two specifies whether to wait for read events and/or write
+ The first two specify whether to wait for read events and/or write
events. A fired read event will call
<seealso marker="driver_entry#ready_input">ready_input</seealso>
while a fired write event will call
<seealso marker="driver_entry#ready_output">ready_output</seealso>.
</p>
<note>
- <p>Some OS (Windows) does not differ between read and write events.
+ <p>Some OS (Windows) do not differentiate between read and write events.
The call-back for a fired event then only depends on the value of <c>mode</c>.</p>
</note>
<p><c>ERL_DRV_USE</c> specifies if we are using the event object or if we want to close it.
@@ -834,9 +826,9 @@ typedef struct ErlIOVec {
as before. But it is recommended to update them to use <c>ERL_DRV_USE</c> and
<c>stop_select</c> to make sure that event objects are closed in a safe way.</p>
</note>
- <p>The return value is 0 (Failure, -1, only if the
+ <p>The return value is 0 (failure, -1, only if the
<c>ready_input</c>/<c>ready_output</c> is
- <c>NULL</c>.</p>
+ <c>NULL</c>).</p>
</desc>
</func>
<func>
@@ -1076,7 +1068,7 @@ typedef struct ErlIOVec {
array of <c>SysIOVec</c>s. It also returns the number of
elements in <c>vlen</c>. This is the only way to get data
out of the queue.</p>
- <p>Nothing is remove from the queue by this function, that must be done
+ <p>Nothing is removed from the queue by this function, that must be done
with <c>driver_deq</c>.</p>
<p>The returned array is suitable to use with the Unix system
call <c>writev</c>.</p>
@@ -1209,7 +1201,7 @@ typedef struct ErlIOVec {
<fsummary>Stop monitoring a process from a driver</fsummary>
<desc>
<marker id="driver_demonitor_process"></marker>
- <p>This function cancels an monitor created earlier. </p>
+ <p>This function cancels a monitor created earlier. </p>
<p>The function returns 0 if a monitor was removed and &gt; 0
if the monitor did no longer exist.</p>
</desc>
@@ -1326,7 +1318,7 @@ typedef struct ErlIOVec {
<p>This function signals to erlang that the driver has
encountered an EOF and should be closed, unless the port was
opened with the <c>eof</c> option, in that case eof is sent
- to the port. Otherwise, the port is close and an
+ to the port. Otherwise, the port is closed and an
<c>'EXIT'</c> message is sent to the port owner process.</p>
<p>The return value is 0.</p>
</desc>
@@ -1349,8 +1341,8 @@ typedef struct ErlIOVec {
(<c>driver_failure</c>).</p>
<p>The driver should fail only when in severe error situations,
when the driver cannot possibly keep open, for instance
- buffer allocation gets out of memory. Normal errors is more
- appropriate to handle with sending error codes with
+ buffer allocation gets out of memory. For normal errors
+ it is more appropriate to send error codes with
<c>driver_output</c>.</p>
<p>The return value is 0.</p>
</desc>
@@ -1371,7 +1363,7 @@ typedef struct ErlIOVec {
<p>This function returns the process id of the process that
made the current call to the driver. The process id can be
used with <c>driver_send_term</c> to send back data to the
- caller. <c>driver_caller()</c> only return valid data
+ caller. <c>driver_caller()</c> only returns valid data
when currently executing in one of the following driver
callbacks:</p>
<taglist>
@@ -1409,7 +1401,7 @@ typedef struct ErlIOVec {
tuple, the elements are given first, and then the tuple
term, with a count. Likewise for lists.</p>
<p>A tuple must be specified with the number of elements. (The
- elements precedes the <c>ERL_DRV_TUPLE</c> term.)</p>
+ elements precede the <c>ERL_DRV_TUPLE</c> term.)</p>
<p>A list must be specified with the number of elements,
including the tail, which is the last term preceding
<c>ERL_DRV_LIST</c>.</p>
@@ -1518,7 +1510,7 @@ ERL_DRV_EXT2TERM char *buf, ErlDrvUInt len
};
driver_output_term(port, spec, sizeof(spec) / sizeof(spec[0]));
]]></code>
- <p>If you want to pass a binary and doesn't already have the content
+ <p>If you want to pass a binary and don't already have the content
of the binary in an <c>ErlDrvBinary</c>, you can benefit from using
<c>ERL_DRV_BUF2BINARY</c> instead of creating an <c>ErlDrvBinary</c>
via <c>driver_alloc_binary()</c> and then pass the binary via
@@ -1565,7 +1557,7 @@ ERL_DRV_EXT2TERM char *buf, ErlDrvUInt len
<em>other</em> processes than the port owner process. The
<c>receiver</c> parameter specifies the process to receive
the data.</p>
- <p>The parameters <c>term</c> and <c>n</c> does the same thing
+ <p>The parameters <c>term</c> and <c>n</c> do the same thing
as in <seealso marker="#driver_output_term">driver_output_term</seealso>.</p>
<p>This function is only thread-safe when the emulator with SMP
support is used.</p>
@@ -1660,7 +1652,7 @@ ERL_DRV_EXT2TERM char *buf, ErlDrvUInt len
<desc>
<marker id="driver_lock_driver"></marker>
<p>This function locks the driver used by the port <c>port</c>
- in memory for the rest of the emulator process
+ in memory for the rest of the emulator process'
lifetime. After this call, the driver behaves as one of Erlang's
statically linked in drivers.</p>
</desc>
@@ -1904,7 +1896,7 @@ ERL_DRV_EXT2TERM char *buf, ErlDrvUInt len
corresponding to one of the involved thread identifiers
has terminated since the thread identifier was saved,
the result of <c>erl_drv_equal_tids()</c> might not give
- expected result.
+ the expected result.
</p></note>
<p>This function is thread-safe.</p>
</desc>
diff --git a/erts/epmd/src/epmd.c b/erts/epmd/src/epmd.c
index 65ff0cd6b2..e94533f0ba 100644
--- a/erts/epmd/src/epmd.c
+++ b/erts/epmd/src/epmd.c
@@ -433,7 +433,7 @@ static void usage(EpmdVars *g)
fprintf(stderr, " List names registered with the currently "
"running epmd\n");
fprintf(stderr, " -kill\n");
- fprintf(stderr, " Kill the currently runniing epmd\n");
+ fprintf(stderr, " Kill the currently running epmd\n");
fprintf(stderr, " (only allowed if -names show empty database or\n");
fprintf(stderr, " -relaxed_command_check was given when epmd was started).\n");
fprintf(stderr, " -stop Name\n");
diff --git a/erts/etc/win32/erlsrv/erlsrv_service.c b/erts/etc/win32/erlsrv/erlsrv_service.c
index a58ee862c5..8891379643 100644
--- a/erts/etc/win32/erlsrv/erlsrv_service.c
+++ b/erts/etc/win32/erlsrv/erlsrv_service.c
@@ -523,7 +523,7 @@ static BOOL start_a_service(ServerInfo *srvi){
srvi->keys[WorkDir].data.bytes : NULL,
&start,
&(srvi->info))){
- sprintf(errbuff,"Could not start erlang service"
+ sprintf(errbuff,"Could not start erlang service "
"with commandline \"%s\".",
service_name,
execbuff
@@ -924,7 +924,7 @@ static VOID WINAPI service_main_loop(DWORD argc, char **argv){
} else {
DWORD ecode = NO_ERROR;
if(success_wait == NO_SUCCESS_WAIT){
- log_warning("Erlang machine volountarily stopped. "
+ log_warning("Erlang machine voluntarily stopped. "
"The service is not restarted as OnFail "
"is set to ignore.");
} else {
diff --git a/erts/example/next_perm.cc b/erts/example/next_perm.cc
index ee81cb0404..1427cd3979 100644
--- a/erts/example/next_perm.cc
+++ b/erts/example/next_perm.cc
@@ -120,7 +120,7 @@ static void ready_async(ErlDrvData drv_data, ErlDrvThreadData async_data)
ErlDrvPort port = reinterpret_cast<ErlDrvPort>(drv_data);
our_async_data* d = reinterpret_cast<our_async_data*>(async_data);
int n = d->data.size(), result_n = n*2 + 5;
- ErlDrvTermData* result = new ErlDrvTermData[result_n], * rp = result;
+ ErlDrvTermData *result = new ErlDrvTermData[result_n], *rp = result;
*rp++ = ERL_DRV_PORT;
*rp++ = driver_mk_port(port);
for (vector<int>::iterator i = d->data.begin();
diff --git a/lib/kernel/doc/src/inet.xml b/lib/kernel/doc/src/inet.xml
index a22c0a8346..f05a224f33 100644
--- a/lib/kernel/doc/src/inet.xml
+++ b/lib/kernel/doc/src/inet.xml
@@ -432,7 +432,7 @@ fe80::204:acff:fe17:bf38
</desc>
</func>
<func>
- <name>port(Socket) -> {ok, Port}</name>
+ <name>port(Socket) -> {ok, Port} | {error, any()}</name>
<fsummary>Return the local port number for a socket</fsummary>
<type>
<v>Socket = socket()</v>
diff --git a/lib/stdlib/doc/src/binary.xml b/lib/stdlib/doc/src/binary.xml
index c5eb81a86a..c81023862e 100644
--- a/lib/stdlib/doc/src/binary.xml
+++ b/lib/stdlib/doc/src/binary.xml
@@ -485,7 +485,7 @@
<code>
1> Bin = &lt;&lt;1,2,3,4,5,6,7,8,9,10&gt;&gt;.
-2> binary:part(Bin,{byte_size(Bin), -5)).
+2> binary:part(Bin,{byte_size(Bin), -5}).
&lt;&lt;6,7,8,9,10&gt;&gt;
</code>
diff --git a/lib/stdlib/doc/src/zip.xml b/lib/stdlib/doc/src/zip.xml
index 4d98a20206..529a70a23d 100644
--- a/lib/stdlib/doc/src/zip.xml
+++ b/lib/stdlib/doc/src/zip.xml
@@ -34,11 +34,11 @@
<module>zip</module>
<modulesummary>Utility for reading and creating 'zip' archives.</modulesummary>
<description>
- <p>The <c>zip</c> module archives and extract files to and from a zip
+ <p>The <c>zip</c> module archives and extracts files to and from a zip
archive. The zip format is specified by the "ZIP Appnote.txt" file
available on PKWare's website www.pkware.com.</p>
<p>The zip module supports zip archive versions up to 6.1. However,
- password-protection and Zip64 is not supported.</p>
+ password-protection and Zip64 are not supported.</p>
<p>By convention, the name of a zip file should end in "<c>.zip</c>".
To abide to the convention, you'll need to add "<c>.zip</c>" yourself
to the name.</p>
@@ -52,7 +52,7 @@
<seealso marker="#unzip_2">unzip/2</seealso> function. (They are
also available as <c>extract</c>.)</p>
<p>To fold a function over all files in a zip archive, use the
- <seealso marker="#foldl_3">foldl_3</seealso>.</p>
+ <seealso marker="#foldl_3">foldl_3</seealso> function.</p>
<p>To return a list of the files in a zip archive, use the
<seealso marker="#list_dir_1">list_dir/1</seealso> or the
<seealso marker="#list_dir_2">list_dir/2</seealso> function. (They
@@ -155,13 +155,13 @@ zip_file() </code>
<p>Files will be compressed using the DEFLATE compression, as
described in the Appnote.txt file. However, files will be
stored without compression if they already are compressed.
- The <c>zip/2</c> and <c>zip/3</c> checks the file extension
+ The <c>zip/2</c> and <c>zip/3</c> functions check the file extension
to see whether the file should be stored without compression.
Files with the following extensions are not compressed:
<c>.Z</c>, <c>.zip</c>, <c>.zoo</c>, <c>.arc</c>, <c>.lzh</c>,
<c>.arj</c>.</p>
<p>It is possible to override the default behavior and
- explicitly control what types of files that should be
+ explicitly control what types of files should be
compressed by using the <c>{compress, What}</c> and
<c>{uncompress, What}</c> options. It is possible to have
several <c>compress</c> and <c>uncompress</c> options. In
@@ -208,7 +208,7 @@ zip_file() </code>
</item>
<tag><c>{compress, What}</c></tag>
<item>
- <p>Controls what types of files that will be
+ <p>Controls what types of files will be
compressed. It is by default set to <c>all</c>. The
following values of <c>What</c> are allowed:</p>
<taglist>
@@ -228,7 +228,7 @@ zip_file() </code>
</item>
<tag><c>{uncompress, What}</c></tag>
<item>
- <p>Controls what types of files that will be uncompressed. It is by
+ <p>Controls what types of files will be uncompressed. It is by
default set to <c>[".Z",".zip",".zoo",".arc",".lzh",".arj"]</c>.
The following values of <c>What</c> are allowed:</p>
<taglist>
@@ -292,7 +292,7 @@ zip_file() </code>
<p>By default, the <c>open/2</c> function will open the
zip file in <c>raw</c> mode, which is faster but does not allow
a remote (erlang) file server to be used. Adding <c>cooked</c>
- to the mode list will override the default and open zip file
+ to the mode list will override the default and open the zip file
without the <c>raw</c> option. The same goes for the files
extracted.</p>
</item>
@@ -301,7 +301,7 @@ zip_file() </code>
<p>By default, all existing files with the same name as file in
the zip archive will be overwritten. With the <c>keep_old_files</c>
option, the <c>unzip/2</c> function will not overwrite any existing
- files. Not that even with the <c>memory</c> option given, which
+ files. Note that even with the <c>memory</c> option given, which
means that no files will be overwritten, files existing will be
excluded from the result.</p>
</item>
@@ -418,7 +418,7 @@ zip_file() </code>
<p>By default, the <c>open/2</c> function will open the
zip file in <c>raw</c> mode, which is faster but does not allow
a remote (erlang) file server to be used. Adding <c>cooked</c>
- to the mode list will override the default and open zip file
+ to the mode list will override the default and open the zip file
without the <c>raw</c> option.</p>
</item>
</taglist>
diff --git a/system/doc/efficiency_guide/advanced.xml b/system/doc/efficiency_guide/advanced.xml
index 8126b93a2d..821175bb09 100644
--- a/system/doc/efficiency_guide/advanced.xml
+++ b/system/doc/efficiency_guide/advanced.xml
@@ -34,7 +34,7 @@
<p>A good start when programming efficiently is to have knowledge about
how much memory different data types and operations require. It is
implementation-dependent how much memory the Erlang data types and
- other items consume, but here are some figures for
+ other items consume, but here are some figures for the
erts-5.2 system (OTP release R9B). (There have been no significant
changes in R13.)</p>
diff --git a/system/doc/efficiency_guide/binaryhandling.xml b/system/doc/efficiency_guide/binaryhandling.xml
index 3628d7a232..425d6308cf 100644
--- a/system/doc/efficiency_guide/binaryhandling.xml
+++ b/system/doc/efficiency_guide/binaryhandling.xml
@@ -114,7 +114,7 @@ my_binary_to_list(<<>>) -> [].]]></code>
data. For each field that is matched out of a binary, the position in the
match context will be incremented.</p>
- <p>In R11B, a match context was only using during a binary matching
+ <p>In R11B, a match context was only used during a binary matching
operation.</p>
<p>In R12B, the compiler tries to avoid generating code that
@@ -205,7 +205,7 @@ Bin4 = <<Bin1/binary,17>>, %% 5 !!!
ProcBin for the binary. The reason is that the binary object can be
moved (reallocated) during an append operation, and when that happens
the pointer in the ProcBin must be updated. If there would be more than
- on ProcBin pointing to the binary object, it would not be possible to
+ one ProcBin pointing to the binary object, it would not be possible to
find and update all of them.</p>
<p>Therefore, certain operations on a binary will mark it so that
@@ -291,7 +291,7 @@ my_binary_to_list(<<>>) -> [].]]></code>
that initializes the matching operation will basically do nothing
when it sees that it was passed a match context instead of a binary.</p>
- <p>When the end of the binary is reached and second clause matches,
+ <p>When the end of the binary is reached and the second clause matches,
the match context will simply be discarded (removed in the next
garbage collection, since there is no longer any reference to it).</p>
diff --git a/system/doc/efficiency_guide/drivers.xml b/system/doc/efficiency_guide/drivers.xml
index 9fe54fb19a..1967fd7ada 100644
--- a/system/doc/efficiency_guide/drivers.xml
+++ b/system/doc/efficiency_guide/drivers.xml
@@ -40,7 +40,7 @@
any code in a driver.</p>
<p>By default, that lock will be at the driver level, meaning that
- if several ports has been opened to the same driver, only code for
+ if several ports have been opened to the same driver, only code for
one port at the same time can be running.</p>
<p>A driver can be configured to instead have one lock for each port.</p>
diff --git a/system/doc/efficiency_guide/functions.xml b/system/doc/efficiency_guide/functions.xml
index fe14a4f000..6be49dd7c9 100644
--- a/system/doc/efficiency_guide/functions.xml
+++ b/system/doc/efficiency_guide/functions.xml
@@ -127,7 +127,7 @@ map_pairs2(_Map, [_|_]=Xs, [] ) ->
map_pairs2(Map, [X|Xs], [Y|Ys]) ->
[Map(X, Y)|map_pairs2(Map, Xs, Ys)].]]></code>
- <p>the compiler is free rearrange the clauses. It will generate code
+ <p>the compiler is free to rearrange the clauses. It will generate code
similar to this</p>
<p><em>DO NOT (already done by the compiler)</em></p>
diff --git a/system/doc/efficiency_guide/processes.xml b/system/doc/efficiency_guide/processes.xml
index a25ec53370..b75be7d531 100644
--- a/system/doc/efficiency_guide/processes.xml
+++ b/system/doc/efficiency_guide/processes.xml
@@ -105,7 +105,7 @@ loop() ->
<seealso marker="erts:erlang#spawn_opt/4">spawn_opt/4</seealso>.</p>
<p>The gain is twofold: Firstly, although the garbage collector will
- grow the heap, it will it grow it step by step, which will be more
+ grow the heap, it will grow it step by step, which will be more
costly than directly establishing a larger heap when the process
is spawned. Secondly, the garbage collector may also shrink the
heap if it is much larger than the amount of data stored on it;
@@ -172,7 +172,7 @@ days_in_month(M) ->
<p>Shared sub-terms are <em>not</em> preserved when a term is sent
to another process, passed as the initial process arguments in
the <c>spawn</c> call, or stored in an ETS table.
- That is an optimization. Most applications do not send message
+ That is an optimization. Most applications do not send messages
with shared sub-terms.</p>
<p>Here is an example of how a shared sub-term can be created:</p>
@@ -237,8 +237,8 @@ true
<section>
<title>The SMP emulator</title>
- <p>The SMP emulator (introduced in R11B) will take advantage of
- multi-core or multi-CPU computer by running several Erlang schedulers
+ <p>The SMP emulator (introduced in R11B) will take advantage of a
+ multi-core or multi-CPU computer by running several Erlang scheduler
threads (typically, the same as the number of cores). Each scheduler
thread schedules Erlang processes in the same way as the Erlang scheduler
in the non-SMP emulator.</p>
diff --git a/system/doc/efficiency_guide/profiling.xml b/system/doc/efficiency_guide/profiling.xml
index 65d13408bc..8be1c7175d 100644
--- a/system/doc/efficiency_guide/profiling.xml
+++ b/system/doc/efficiency_guide/profiling.xml
@@ -74,7 +74,7 @@
<title>What to look for</title>
<p>When analyzing the result file from the profiling activity
you should look for functions that are called many
- times and have a long "own" execution time (time excluded calls
+ times and have a long "own" execution time (time excluding calls
to other functions). Functions that just are called very
many times can also be interesting, as even small things can add
up to quite a bit if they are repeated often. Then you need to
@@ -87,7 +87,7 @@
<item>Are there redundant tests that can be removed? </item>
<item>Is there some expression calculated giving the same result
each time? </item>
- <item>Is there other ways of doing this that are equivalent and
+ <item>Are there other ways of doing this that are equivalent and
more efficient?</item>
<item>Can I use another internal data representation to make
things more efficient? </item>
@@ -138,7 +138,7 @@
<p><c>cprof</c> is something in between <c>fprof</c> and
<c>cover</c> regarding features. It counts how many times each
function is called when the program is run, on a per module
- basis. <c>cprof</c> has a low performance degradation (versus
+ basis. <c>cprof</c> has a low performance degradation effect (versus
<c>fprof</c> and <c>eprof</c>) and does not need to recompile
any modules to profile (versus <c>cover</c>).</p>
</section>
@@ -231,7 +231,7 @@
consistent from run to run. The disadvantage is that the time
spent in the operating system kernel (such as swapping and I/O)
are not included. Therefore, measuring CPU time is misleading if
- any I/O (file or sockets) are involved.</p>
+ any I/O (file or socket) is involved.</p>
<p>It is probably a good idea to do both wall-clock measurements and
CPU time measurements.</p>
@@ -239,18 +239,18 @@
<p>Some additional advice:</p>
<list type="bulleted">
- <item>The granularity of both types measurement could be quite
+ <item>The granularity of both types of measurement could be quite
high so you should make sure that each individual measurement
lasts for at least several seconds.</item>
<item>To make the test fair, each new test run should run in its own,
- newly created Erlang process. Otherwise, if all tests runs in the
+ newly created Erlang process. Otherwise, if all tests run in the
same process, the later tests would start out with larger heap sizes
- and therefore probably does less garbage collections. You could
+ and therefore probably do less garbage collections. You could
also consider restarting the Erlang emulator between each test.</item>
<item>Do not assume that the fastest implementation of a given algorithm
- on computer architecture X also is the fast on computer architecture Y.</item>
+ on computer architecture X also is the fastest on computer architecture Y.</item>
</list>
</section>
diff --git a/system/doc/efficiency_guide/tablesDatabases.xml b/system/doc/efficiency_guide/tablesDatabases.xml
index 4b53348c4c..2f5103a08b 100644
--- a/system/doc/efficiency_guide/tablesDatabases.xml
+++ b/system/doc/efficiency_guide/tablesDatabases.xml
@@ -280,9 +280,9 @@ lists:filter(fun(X) -> X#person.name == "Bryan" end, TabList),
<p>A simple solution would be to use the <c>name</c> field as
the key instead of the <c>idno</c> field, but that would cause
problems if the names were not unique. A more general solution
- would be create a second table with name as key and idno as
- data, i.e. to index (invert) the table with regards to the
- <c>name</c> field. The second table would of course have to be
+ would be to create a second table with <c>name</c> as key and
+ <c>idno</c> as data, i.e. to index (invert) the table with regards
+ to the <c>name</c> field. The second table would of course have to be
kept consistent with the master table. Mnesia could do this
for you, but a home brew index table could be very efficient
compared to the overhead involved in using Mnesia.</p>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-11 01:40:47 +0000