mention threads in docs

Author: fijal

BUGS

@@ -0,0 +1 @@
+On windows, we handle all the threads, not just ones that are running.

README-develop.md

@@ -0,0 +1,27 @@
+vmprof is a delicate piece of software. Following considerations should
+be present when developing it.
+
+Supported platform combinations (all combinations are supported):
+
+* pypy (>=4.1), cpython
+
+* windows, os x and linux
+
+CPython should be tested on both TeamCity and Travis, PyPy is more
+patchy since there is never a new enough version on either. Since PyPy
+only exercises the pure python part, please test it each time you change
+and interface between _vmprof and vmprof.
+
+Signals
+=======
+
+On OS X and Linux we handle signal handlers. This means that we have
+to be very very careful at what we can and cannot do. Notably, we can't
+use malloc, locks or refcounting in any of the signal handlers. Python data
+should be read-only and we should be prepared to read garbage or NULL
+from anything.
+
+On windows we use an external thread, so it's an imperative we freeze
+the thread we're inspecting. It's possible that the interpreter state
+handling is not thread safe in a way it should be, investigate how we
+can improve it.

docs/index.rst

@@ -14,7 +14,8 @@ continuously taking samples of the call stack of the running program, at a
 given frequency. This is similar to tools like `vtune`_ or `gperftools`_: the
 main difference is that those tools target C and C-like languages and are not
 very helpful to profile higher-level languages which run on top of a virtual
-machine, while vmprof is designed specifically for them.
+machine, while vmprof is designed specifically for them. vmprof is also thread
+safe and will correctly display the information regardless of usage of threads.
 
 There are three primary modes. The recommended one is to use our server
 infrastructure for a web-based visualization of the result::