From bae3d4b96fd0c0c3feef1e5e9757591adb1e0326 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 20 Dec 2016 02:35:45 +0100 Subject: [PATCH] mark a solution how to create a safeguard against deadlock on session shutdown ....if by some weird coincidence, a command dispatched into the session happens to trigger session shutdown or re-loading, this will cause a deadlock, since decommissioning of session data structures must wait for the ProcDispatcher to disable command processing -- and this will obviously never happen when in a callstack below some command execution! --- src/backend/thread-wrapper.hpp | 1 + src/proc/control/proc-dispatcher.cpp | 2 + wiki/thinkPad.ichthyo.mm | 68 +++++++++++++++++++++++++++- 3 files changed, 69 insertions(+), 2 deletions(-) diff --git a/src/backend/thread-wrapper.hpp b/src/backend/thread-wrapper.hpp index 4a53b6b12..12c7fa475 100644 --- a/src/backend/thread-wrapper.hpp +++ b/src/backend/thread-wrapper.hpp @@ -197,6 +197,7 @@ namespace backend { return thread_; } + ////////////////////////////////////////////////////////////////////////////TICKET #1054 : API to find out if current execution is *in* this thread! /** Synchronisation barrier. In the function executing in this thread * needs to be a corresponding Thread::syncPoint() call. Blocking until diff --git a/src/proc/control/proc-dispatcher.cpp b/src/proc/control/proc-dispatcher.cpp index 89c18e654..560f1a2b0 100644 --- a/src/proc/control/proc-dispatcher.cpp +++ b/src/proc/control/proc-dispatcher.cpp @@ -227,6 +227,8 @@ namespace control { ////////////////////////////////////////////////////////////////TODO any idea how to achieve that? The lock does not help us, since it is recursive and //////////////////////////////////////////////////////////////// ... since command/builder execution itself is not performed in a locked section. //////////////////////////////////////////////////////////////// ... Possibly we'll just have to plant a ThreadLocal to mark this dangerous situation. + + ///////////////////////////////////////////////////////////////////////////////TICKET #1054 : can be done by relying on some internals of our thread handling framework } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 38628f648..614e145a2 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -11113,7 +11113,8 @@ - + + @@ -11122,6 +11123,69 @@ + + + + + + +

+ Ticket #1054 +

+ + + + + + + + + + + + + + + + +

+ ...und "self" == LumieraThrea* == "handle" (im Wrapper). +

+

+ +

+

+ D.h. solange der Wrapper lebt (!), kann er selber leicht feststellen, ob die aktuelle Ausführung +

+

+ auch in einem Thread stattfindet, der +

+
    +
  • + von unserem Threadpool gestartet wurde +
    • +
  • + ein Thread-Handle hat, das mit dem Handle dieses Wrappers identisch ist. +
    • +
+

+ +

+

+ Das Schöne bei diesem Ansatz ist, daß man dafür weder das Handle exponieren muß, +

+

+ noch irgendwelche komischen Policies aufmachen. Solange es das Objekt gibt, klappt das. +

+

+ OO rocks! +

+ + + + + + @@ -11207,7 +11271,7 @@ - +