[pypy-commit] extradoc extradoc: another comment

[Raemi]

Author: Remi Meier <remi.meier at inf.ethz.ch>
Branch: extradoc
Changeset: r5234:18ba53e1a5b4
Date: 2014-05-05 13:54 +0200
http://bitbucket.org/pypy/extradoc/changeset/18ba53e1a5b4/

Log:	another comment

diff --git a/talk/icooolps2014/position-paper.tex b/talk/icooolps2014/position-paper.tex
--- a/talk/icooolps2014/position-paper.tex
+++ b/talk/icooolps2014/position-paper.tex
@@ -274,14 +274,15 @@
 however be very simple too. One could simply use one lock per library
 to avoid this issue.
 
-In the end, fine-grained locking can transparently replace the GIL
-and therefore parallelise existing applications, generally without any
+In the end, fine-grained locking can transparently replace the GIL and
+therefore parallelise existing applications, generally without any
 changes\footnote{There are rare cases where not having atomic
-bytecodes actually changes the semantics.}
-It does however not provide a better synchronisation
-mechanism to the application like e.g. atomic blocks.
+  bytecodes actually changes the semantics.}. An implementation has to
+follow the GIL semantics very closely, otherwise it may expose some
+latent data races in existing applications which are just not exposed
+with a GIL. This approach does however not provide a better parallelising
+synchronisation mechanism to the application like e.g. atomic blocks.
 
-\cfbolz{I think you should mention the commented out point below, that a lot of existing code contains latent races / deadlocks that are just not exposed in a GIL-full world}
 %% - support of atomic blocks?\\
 %% - hard to get right (deadlocks, performance, lock-granularity)\\
 %% - very hard to get right for a large language\\