From 7762660e35baba18f4fe8e83c8378db713541572 Mon Sep 17 00:00:00 2001
From: Sverker Eriksson 
Date: Mon, 21 Jan 2019 21:05:16 +0100
Subject: stdlib: Add ets doc note about subtle iteration oddities
as it has been made more relevant with the introduction of
write_concurrency for ordered_set.
---
 lib/stdlib/doc/src/ets.xml | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
(limited to 'lib/stdlib/doc/src')
diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml
index e67397c6fd..7594514b29 100644
--- a/lib/stdlib/doc/src/ets.xml
+++ b/lib/stdlib/doc/src/ets.xml
@@ -188,6 +188,31 @@
         is used to keep the table fixated during the entire traversal.
       
     
+    
+      Even though the access of a single object is always guaranteed to be
+      atomic and isolated, each traversal
+      through a table to find the next key is not done with such guarantees. This is often
+      not a problem, but may cause rare subtle "unexpected" effects if a concurrent
+      process inserts objects during a traversal. For example, consider one
+      process doing
+
+ets:new(t, [ordered_set, named_table]),
+ets:insert(t, {1}),
+ets:insert(t, {2}),
+ets:insert(t, {3}),
+
+      A concurrent call to ets:first(t), done by another
+      process, may then in rare cases return 2 even though
+      2 has never existed in the table ordered as the first key. In
+      the same way, a concurrent call to ets:next(t, 1) may return
+      3 even though 3 never existed in the table
+      ordered directly after 1.
+      Effects like this are improbable but possible. The probability will
+      further be reduced (if not vanish) if table option
+      write_concurrency
+      is not enabled. This can also only be a potential concern for
+      ordered_set where the traversal order is defined.
+