<commit_before><?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>
  <header>
    <copyright>
      <year>1996</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>ets</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
  </header>
  <module>ets</module>
  <modulesummary>Built-In Term Storage</modulesummary>
  <description>
    <p>This module is an interface to the Erlang built-in term storage
      BIFs. These provide the ability to store very large quantities of
      data in an Erlang runtime system, and to have constant access
      time to the data. (In the case of <c>ordered_set</c>, see below,
      access time is proportional to the logarithm of the number of
      objects stored).</p>
    <p>Data is organized as a set of dynamic tables, which can store
      tuples. Each table is created by a process. When the process
      terminates, the table is automatically destroyed. Every table has
      access rights set at creation.</p>
    <p>Tables are divided into four different types, <c>set</c>,
      <c>ordered_set</c>, <c>bag</c> and <c>duplicate_bag</c>.
      A <c>set</c> or <c>ordered_set</c> table can only have one object
      associated with each key. A <c>bag</c> or <c>duplicate_bag</c> can
      have many objects associated with each key.</p>
    <p>The number of tables stored at one Erlang node is limited.
      The current default limit is approximately 1400 tables. The upper
      limit can be increased by setting the environment variable
      <c>ERL_MAX_ETS_TABLES</c> before starting the Erlang runtime
      system (i.e. with the <c>-env</c> option to
      <c>erl</c>/<c>werl</c>). The actual limit may be slightly higher
      than the one specified, but never lower.</p>
    <p>Note that there is no automatic garbage collection for tables.
      Even if there are no references to a table from any process, it
      will not automatically be destroyed unless the owner process
      terminates. It can be destroyed explicitly by using
      <c>delete/1</c>. The default owner is the process that created the
      table. Table ownership can be transferred at process termination
      by using the <seealso marker="#heir">heir</seealso> option or explicitly
      by calling <seealso marker="#give_away/3">give_away/3</seealso>.</p>
    <p>Some implementation details:</p>
    <list type="bulleted">
      <item>In the current implementation, every object insert and
       look-up operation results in a copy of the object.</item>
      <item><c>'$end_of_table'</c> should not be used as a key since
       this atom is used to mark the end of the table when using
      <c>first</c>/<c>next</c>.</item>
    </list>
    <p>Also worth noting is the subtle difference between
      <em>matching</em> and <em>comparing equal</em>, which is
      demonstrated by the different table types <c>set</c> and
      <c>ordered_set</c>. Two Erlang terms <c>match</c> if they are of
      the same type and have the same value, so that <c>1</c> matches
      <c>1</c>, but not <c>1.0</c> (as <c>1.0</c> is a <c>float()</c>
      and not an <c>integer()</c>). Two Erlang terms <em>compare equal</em> if they either are of the same type and value, or if
      both are numeric types and extend to the same value, so that
      <c>1</c> compares equal to both <c>1</c> and <c>1.0</c>. The
      <c>ordered_set</c> works on the <em>Erlang term order</em> and
      there is no defined order between an <c>integer()</c> and a
      <c>float()</c> that extends to the same value, hence the key
      <c>1</c> and the key <c>1.0</c> are regarded as equal in an
      <c>ordered_set</c> table.</p>
  </description>
  <section>
    <title>Failure</title>
    <p>In general, the functions below will exit with reason
      <c>badarg</c> if any argument is of the wrong format, if the
      table identifier is invalid or if the operation is denied due to
      table access rights (<seealso marker="#protected">protected</seealso>
      or <seealso marker="#private">private</seealso>).</p>
  </section>
  <section><marker id="concurrency"></marker>
    <title>Concurrency</title>
      <p>This module provides some limited support for concurrent access.
       All updates to single objects are guaranteed to be both <em>atomic</em>
       and <em>isolated</em>. This means that an updating operation towards
       a single object will either succeed or fail completely without any
       effect at all (atomicy).
       Nor can any intermediate results of the update be seen by other
       processes (isolation). Some functions that update several objects
       state that they even guarantee atomicy and isolation for the entire
       operation. In database terms the isolation level can be seen as
       "serializable", as if all isolated operations were carried out serially,
       one after the other in a strict order.</p>
      <p>No other support is available within ETS that would guarantee<commit_msg>Fix spelling of "atomicity" in ets.xml<commit_after><?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>
  <header>
    <copyright>
      <year>1996</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>ets</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
  </header>
  <module>ets</module>
  <modulesummary>Built-In Term Storage</modulesummary>
  <description>
    <p>This module is an interface to the Erlang built-in term storage
      BIFs. These provide the ability to store very large quantities of
      data in an Erlang runtime system, and to have constant access
      time to the data. (In the case of <c>ordered_set</c>, see below,
      access time is proportional to the logarithm of the number of
      objects stored).</p>
    <p>Data is organized as a set of dynamic tables, which can store
      tuples. Each table is created by a process. When the process
      terminates, the table is automatically destroyed. Every table has
      access rights set at creation.</p>
    <p>Tables are divided into four different types, <c>set</c>,
      <c>ordered_set</c>, <c>bag</c> and <c>duplicate_bag</c>.
      A <c>set</c> or <c>ordered_set</c> table can only have one object
      associated with each key. A <c>bag</c> or <c>duplicate_bag</c> can
      have many objects associated with each key.</p>
    <p>The number of tables stored at one Erlang node is limited.
      The current default limit is approximately 1400 tables. The upper
      limit can be increased by setting the environment variable
      <c>ERL_MAX_ETS_TABLES</c> before starting the Erlang runtime
      system (i.e. with the <c>-env</c> option to
      <c>erl</c>/<c>werl</c>). The actual limit may be slightly higher
      than the one specified, but never lower.</p>
    <p>Note that there is no automatic garbage collection for tables.
      Even if there are no references to a table from any process, it
      will not automatically be destroyed unless the owner process
      terminates. It can be destroyed explicitly by using
      <c>delete/1</c>. The default owner is the process that created the
      table. Table ownership can be transferred at process termination
      by using the <seealso marker="#heir">heir</seealso> option or explicitly
      by calling <seealso marker="#give_away/3">give_away/3</seealso>.</p>
    <p>Some implementation details:</p>
    <list type="bulleted">
      <item>In the current implementation, every object insert and
       look-up operation results in a copy of the object.</item>
      <item><c>'$end_of_table'</c> should not be used as a key since
       this atom is used to mark the end of the table when using
      <c>first</c>/<c>next</c>.</item>
    </list>
    <p>Also worth noting is the subtle difference between
      <em>matching</em> and <em>comparing equal</em>, which is
      demonstrated by the different table types <c>set</c> and
      <c>ordered_set</c>. Two Erlang terms <c>match</c> if they are of
      the same type and have the same value, so that <c>1</c> matches
      <c>1</c>, but not <c>1.0</c> (as <c>1.0</c> is a <c>float()</c>
      and not an <c>integer()</c>). Two Erlang terms <em>compare equal</em> if they either are of the same type and value, or if
      both are numeric types and extend to the same value, so that
      <c>1</c> compares equal to both <c>1</c> and <c>1.0</c>. The
      <c>ordered_set</c> works on the <em>Erlang term order</em> and
      there is no defined order between an <c>integer()</c> and a
      <c>float()</c> that extends to the same value, hence the key
      <c>1</c> and the key <c>1.0</c> are regarded as equal in an
      <c>ordered_set</c> table.</p>
  </description>
  <section>
    <title>Failure</title>
    <p>In general, the functions below will exit with reason
      <c>badarg</c> if any argument is of the wrong format, if the
      table identifier is invalid or if the operation is denied due to
      table access rights (<seealso marker="#protected">protected</seealso>
      or <seealso marker="#private">private</seealso>).</p>
  </section>
  <section><marker id="concurrency"></marker>
    <title>Concurrency</title>
      <p>This module provides some limited support for concurrent access.
       All updates to single objects are guaranteed to be both <em>atomic</em>
       and <em>isolated</em>. This means that an updating operation towards
       a single object will either succeed or fail completely without any
       effect at all (atomicity).
       Nor can any intermediate results of the update be seen by other
       processes (isolation). Some functions that update several objects
       state that they even guarantee atomicity and isolation for the entire
       operation. In database terms the isolation level can be seen as
       "serializable", as if all isolated operations were carried out serially,
       one after the other in a strict order.</p>
      <p>No other support is available within ETS that would guarantee
{'fraction_non_alphanumeric': 0.09643514057983708, 'fraction_numerical': 0.0061312078479460455, 'mean_word_length': 3.0822309617447265, 'pattern_counts': {'":': 0, '<': 317, '<?xml version=': 2, '>': 317, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 3}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6243828', 'n_tokens_mistral': 3245, 'n_tokens_neox': 3157, 'n_words': 1426}