Doc: Rewrite section on threaded event loops

- Focus on signals instead of events; programs rarely need to call
  QCoreApplication::postEvent() manually
- Mention QMetaMethod::invokeMethod()
- Reduce verbosity

Change-Id: I170b96bd0134c0bc102ef1a344d4f0b88e504f86
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>

src/corelib/doc/src/threads-basics.qdoc

@@ -277,26 +277,26 @@
 
     \section2 Using the Event Loop to Prevent Data Corruption
 
-    The event loops of Qt are a very valuable tool for inter-thread
+    Qt's \l{The Event System}{event system} is very useful for inter-thread
-    communication. Every thread may have its own event loop. A safe way of
+    communication. Every thread may have its own event loop. To call a slot (or
-    calling a slot in another thread is by placing that call in another
+    any \l{Q_INVOKABLE}{invokable} method) in another thread, place that call in
-    thread's event loop. This ensures that the target object finishes the
+    the target thread's event loop. This lets the target thread finish its current
-    method that is currently running before another method is started.
+    task before the slot starts running, while the original thread continues
+    running in parallel.
 
-    So how is it possible to put a method invocation in an event loop? Qt has
+    To place an invocation in an event loop, make a queued \l{Signals & Slots}
-    two ways of doing this. One way is via queued signal-slot connections; the
+    {signal-slot} connection. Whenever the signal is emitted, its arguments will
-    other way is to post an event with QCoreApplication::postEvent(). A queued
+    be recorded by the event system. The thread that the signal receiver
-    signal-slot connection is a signal slot connection that is executed
+    \l{QObject#Thread Affinity}{lives in} will then run the slot. Alternatively,
-    asynchronously. The internal implementation is based on posted events. The
+    call QMetaObject::invokeMethod() to achieve the same effect without signals.
-    arguments of the signal are put into the event loop and the signal method
+    In both cases, a \l{Qt::QueuedConnection}{queued connection} must be used
-    returns immediately.
+    because a \l{Qt::DirectConnection}{direct connection} bypasses the event
+    system and runs the method immediately in the current thread.
 
-    The connected slot will be executed at a time which depends on what else is
+    There is no risk of deadlocks when using the event system for thread
-    in the event loop.
+    synchronization, unlike using low-level primitives.
 
-    Communication via the event loop eliminates the deadlock problem we face
+    \sa QThread::exec(), {Threads and QObjects}
-    when using mutexes. This is why we recommend using the event loop rather
-    than locking an object using a mutex.
 
     \section2 Dealing with Asynchronous Execution