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

106 lines
2.9 KiB
C++
Raw Permalink 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: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2023, Hermann Vosseler <Ichthyostega@web.de>
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
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** 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. See the file COPYING for further details.
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
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
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
/** @file thread-wrapper-autonomous-test.cpp
** unit test \ref ThreadWrapperAutonomous_test
*/
#include "lib/test/run.hpp"
Library: reorganise test helpers and cover logging tracker object ...these features are now used quite regularly, and so a dedicated documentation test seems indicated. Actually my intention is to add a tracking allocator to these test helpers (and then to use that to verify the custom allocator usage of `lib::Several`)
2024-06-15 18:14:00 +02:00
#include "lib/test/tracking-dummy.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"
#include <atomic>
#include <chrono>
using test::Test;
Library: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +02:00
using std::atomic_bool;
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
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{
/*******************************************************************//**
* @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()
{
Library: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +02:00
atomic_bool didRun{false};
launchDetached ("anarchy", [&]{ didRun = true; });
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: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +02:00
CHECK (didRun); // verify the effect has taken place
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
}
/**
* @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);
sleep_for (5ms);
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: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +02:00
// Note the Dummy member allows to watch instance lifecycle
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());
Library: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +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
launchDetached<TestThread> (&TestThread::doIt, 55);
CHECK (0 < Dummy::checksum());
Library: test coverage for self-managed thread ...extract and improve the tuple-rewriting function ...improve instance tracking test dummy objects ...complete test coverage and verify proper memory handling
2023-10-11 21:06:56 +02:00
sleep_for (1ms);
CHECK (55 == Dummy::checksum());
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
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