Can we create a new category named Development?

[stefanos82]

@aristocratos It would help for development discussion(s) since we have no Discord / IRC / other channel as our medium for real-time discussions.

I have questions about POSIX Thread versus Concurrency Library support since C++11 and onward that we could use instead, especially C++20's std::jthread that

The class jthread represents a single thread of execution. It has the same general behavior as std::thread, except that jthread automatically rejoins on destruction, and can be cancelled/stopped in certain situations.

[aristocratos]

@stefanos82
POSIX threads are used to be able to block signals in the thread, see:

btop/src/btop.cpp

Lines 416 to 423 in d58a17a

	void * _runner(void *) {
	//? Block some signals in this thread to avoid deadlock from any signal handlers trying to stop this thread
	sigemptyset(&mask);
	// sigaddset(&mask, SIGINT);
	// sigaddset(&mask, SIGTSTP);
	sigaddset(&mask, SIGWINCH);
	sigaddset(&mask, SIGTERM);
	pthread_sigmask(SIG_BLOCK, &mask, NULL);

If the same functionality can be achieved using the standard library, I don't see any issue in changing it. But didn't find a way to do it when I wrote that section, that was however a while ago and it's quite possible I missed something.

[stefanos82]

By all means I'm no expert in POSIX Threads nor in modern C++; but I'm doing my best to learn the deep parts of this language and I have to admit, I'm new to modern C++'s concurrency support.

I have found an example online which seems like it produces what you would expect it to do via signals: https://godbolt.org/z/YvEhzf1c3

[aristocratos]

I'm talking about POSIX signals from the OS. The secondary thread need to be able to suppress them or the program is gonna end up in a deadlock when the main thread responds to them. There is ways around this, but all the signal handling would need to be rewritten.

[stefanos82]

I understand.

The new concurrency library support offers ways to modernize the code, but seems like we both need to study such features in depth before possible code improvement.

[aristocratos]

I believe the issue is that std::thread will use any available OS thread type, which in most cases will be pthread (POSIX threads), however since it's not guaranteed to be POSIX threads the functionality for masking POSIX signals is not exposed.
Therefor I need to force the issue by directly using pthread instead of std::thread.

Since I've wrapped locks and other C functions related to the threads in RAII wrapper classes, it is already "safe" in regards to how std::thread handles threads.

If you look at the early commits you'll see that I initially used std::thread but had to change to pthread for this particular reason.

[stefanos82]

I believe the issue is that std::thread will use any available OS thread type, which in most cases will be pthread (POSIX threads), however since it's not guaranteed to be POSIX threads the functionality for masking POSIX signals is not exposed. Therefor I need to force the issue by directly using pthread instead of std::thread.

Interesting, how do you handle those signals on Windows that POSIX Thread is not supported by default?

[aristocratos]

Windows isn't POSIX so there is no POSIX signals to handle.

[stefanos82]

One example I have found online that demonstrates how to resolve deadlocks with modern features (scoped_lock) looks like this:

#include <iostream>
#include <chrono>
#include <mutex>
#include <thread>

struct CriticalData
{
    std::mutex mut;
};

void deadLock(CriticalData& a, CriticalData& b)
{
    std::cout << "Thread: " << std::this_thread::get_id() << " first mutex" << '\n'; 

    std::this_thread::sleep_for(std::chrono::milliseconds(1));

    std::cout << "Thread: " << std::this_thread::get_id() << " second mutex" << '\n';
    std::cout << "Thread: " << std::this_thread::get_id() << " get both mutex\n";

    std::scoped_lock(a.mut, b.mut);

    // do something with a and b
}

int main()
{
    CriticalData c1;
    CriticalData c2;

    std::thread t1([&]{deadLock(c1,c2);});
    std::thread t2([&]{deadLock(c2,c1);});

    t1.join();
    t2.join();

    std::cout << '\n';
}

[aristocratos]

That's still no help since the signals are coming from outside in the OS, not inside the program. The signal will be handled by the currently active thread and the signal handler don't know which thread called it.

[stefanos82]

...in other words, C++ concurrency support is for user-space, whereas POSIX Threads are usually used for kernel-space?

Please feel free to correct me whenever I'm wrong, because I want to learn as much as possible around btop's implementation.

[aristocratos]

I don't know about that. It just lacks any apparent way to handle incoming signals.
There is ways around this, for example setup the signal handlers to set a flag and then return and then let the "main loop" handle the signal in a delayed fashion.
It would add a minuscule performance penalty since you need to add some conditional checking at every loop.

[stefanos82]

Seems like there is no standard way to work with OS signal handling via C++ concurrency library (at least it's not obvious to me), but I'm sure developers with more experience than most of us know how to accomplish desired output.

Anyhow, since it works the way it currently does, until we acquire the necessary experience with modern concurrency library support, we should not touch it no matter what!

Thank you @aristocratos for clarifying things to me and thank you for creating the new Development category.

[aristocratos]

until we acquire the necessary experience with modern concurrency library support, we should not touch it no matter what!

Well as I mentioned above it's easily fixable by rewriting the signal handling, but like many other things in need of refactoring, I've just haven't had time to do it yet.

Thank you @aristocratos for clarifying things to me and thank you for creating the new Development category.

No problem 🙂