ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/library/thread-wrapper-autonomous-test.cpp

123 lines
3.4 KiB
C++
Raw Normal View History

Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
/*
ThreadWrapperAutonomous(Test) - launching a self-contained and completely detached thread
Copyright (C) Lumiera.org
2023, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file thread-wrapper-autonomous-test.cpp
** unit test \ref ThreadWrapperAutonomous_test
*/
#include "lib/test/run.hpp"
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
#include "lib/test/testdummy.hpp"
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
#include "lib/thread.hpp"
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
#include "lib/test/diagnostic-output.hpp"///////////////////TODO
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
#include <atomic>
#include <chrono>
using test::Test;
using std::atomic_uint;
using std::this_thread::yield;
using std::this_thread::sleep_for;
Library: policy for self-managed thread ...after resolving the fundamental design problems, a policy mix-in can be defined now for a thread that deletes its own wrapper at the end of the thread-function. Such a setup would allow for »fire-and-forget« threads, but with wrapper and ensuring safe allocations. The prominent use case for such a setup would be the GUI-Thread.
2023-10-10 02:55:23 +02:00
using namespace std::chrono_literals;
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
namespace lib {
namespace test{
namespace { // test parameters
const uint NUM_THREADS = 200;
const uint REPETITIONS = 10;
}
/*******************************************************************//**
* @test a variation of the Thread wrapper to launch a detached thread,
* with automatic memory management for the _thread-object._.
* @see thread.hpp
* @see ThreadWrapper_test
*/
class ThreadWrapperAutonomous_test : public Test
{
virtual void
run (Arg)
{
demonstrateSimpleUsage();
verifyMemoryManagement();
}
/** @test demonstrate simply launching a λ-function into background */
void
demonstrateSimpleUsage()
{
atomic_uint i{0};
Library: policy for self-managed thread ...after resolving the fundamental design problems, a policy mix-in can be defined now for a thread that deletes its own wrapper at the end of the thread-function. Such a setup would allow for »fire-and-forget« threads, but with wrapper and ensuring safe allocations. The prominent use case for such a setup would be the GUI-Thread.
2023-10-10 02:55:23 +02:00
launchDetached ("anarchy", [&]{ ++i; });
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
Library: policy for self-managed thread ...after resolving the fundamental design problems, a policy mix-in can be defined now for a thread that deletes its own wrapper at the end of the thread-function. Such a setup would allow for »fire-and-forget« threads, but with wrapper and ensuring safe allocations. The prominent use case for such a setup would be the GUI-Thread.
2023-10-10 02:55:23 +02:00
sleep_for(1ms);
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
CHECK (i == 1); // verify the effect has taken place
}
/**
* @test verify the detached thread autonomously manages its memory.
*/
void
verifyMemoryManagement()
{
struct TestThread
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
: ThreadHookable
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
{
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
using ThreadHookable::ThreadHookable;
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
Dummy watcher;
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
void
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
doIt (int extra)
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
{
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
watcher.setVal (extra);
SHOW_EXPR(extra)
sleep_for (5ms);
SHOW_EXPR("bye")
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
}
};
Library: allow to bind a member function into self-managed thread Oh my. Yet another hideously complex problem and workaround... Since a week I am like "almost done"
2023-10-11 13:21:08 +02:00
//
CHECK (0 == Dummy::checksum());
//
launchDetached<TestThread> (&TestThread::doIt, 55);
CHECK (0 < Dummy::checksum());
sleep_for (10ms);
CHECK (0 == Dummy::checksum());
Library: identified further use-case variants to cover ...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
2023-10-05 23:32:15 +02:00
}
};
/** Register this test class... */
LAUNCHER (ThreadWrapperAutonomous_test, "function common");
}} // namespace lib::test
Reference in a new issue Copy permalink