File: foregroundlock.h

package info (click to toggle)
kdevelop 4%3A24.12.3-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 71,888 kB
  • sloc: cpp: 290,869; python: 3,626; javascript: 3,518; sh: 1,316; ansic: 703; xml: 401; php: 95; lisp: 66; makefile: 31; sed: 12
file content (97 lines) | stat: -rw-r--r-- 3,138 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
/*
    SPDX-FileCopyrightText: 2010 David Nolden <david.nolden.kdevelop@art-master.de>

    SPDX-License-Identifier: GPL-2.0-or-later
*/

#ifndef KDEVPLATFORM_FOREGROUNDLOCK_H
#define KDEVPLATFORM_FOREGROUNDLOCK_H

#include "utilexport.h"
#include <QObject>
#include <QMutex>
#include <QWaitCondition>

namespace KDevelop {

/**
 * A locking object that locks the resources that are associated to the main thread. When this lock is held,
 * you can call any thread-unsafe functions, because the foreground thread is locked in an event.
 *
 * The lock always becomes available when the foreground thread stops processing events.
 *
 * @warning There is one simple rule you must always follow to prevent deadlocks:
 *                  @em Never lock anything before locking the foreground mutex!!
 *                   That also means that you must not take this lock in contexts where
 *                   you don't know what other mutexes might be locked.
 *
 * @warning Objects that have QObject as base always get the thread they were created in assigned (see thread affinity, QObject::moveToThread),
 *                  which seriously affects the objects functionality regarding signals/slots.
 *                 The foreground lock does not change the thread affinity, so holding the foreground lock does not fully equal being in the foreground.
 *                 It may generally be unsafe to call foreground functions that create QObjects from within the background.
 */
class KDEVPLATFORMUTIL_EXPORT ForegroundLock
{
public:
    explicit ForegroundLock(bool lock = true);
    ~ForegroundLock();
    ForegroundLock(const ForegroundLock& rhs) = delete;
    ForegroundLock& operator=(const ForegroundLock& rhs) = delete;

    void unlock();
    void relock();
    bool tryLock();

    /// Returns whether the current thread holds the foreground lock
    static bool isLockedForThread();

    bool isLocked() const;

private:
    bool m_locked = false;
};

/**
 * Use this object if you want to temporarily release the foreground lock,
 * for example when sleeping in the foreground thread, or when waiting in the foreground
 * thread for a background thread which should get the chance to lock the foreground.
 *
 * While this object is alive, you _must not_ access any non-threadsafe resources
 * that belong to the foreground, and you must not start an event-loop.
 */
class KDEVPLATFORMUTIL_EXPORT TemporarilyReleaseForegroundLock
{
public:
    TemporarilyReleaseForegroundLock();
    ~TemporarilyReleaseForegroundLock();

private:
    TemporarilyReleaseForegroundLock(const TemporarilyReleaseForegroundLock&);
    TemporarilyReleaseForegroundLock& operator=(const TemporarilyReleaseForegroundLock& rhs);
    int m_recursion;
};

#define VERIFY_FOREGROUND_LOCKED Q_ASSERT(KDevelop::ForegroundLock::isLockedForThread());

class KDEVPLATFORMUTIL_EXPORT DoInForeground : public QObject
{
    Q_OBJECT

public:
    DoInForeground();
    ~DoInForeground() override;

    void doIt();

private Q_SLOTS:
    void doInternalSlot();

private:
    virtual void doInternal() = 0;
    QMutex m_mutex;
    QWaitCondition m_wait;
};

}

#endif