[+] Added doxing fingerprint
[*] Use RAII safe lock guard instead of ->Lock(), ->Unlock() that would not be unwound
This commit is contained in:
parent
086de4600f
commit
3f2f66f4ec
BIN
Media/Hello Aurora.png
Normal file
BIN
Media/Hello Aurora.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 115 KiB |
@ -82,9 +82,8 @@ AuUInt32 WELL_NextLong_Unlocked(WELLRand *rand)
|
||||
*/
|
||||
AuUInt32 WELL_NextLong(WELLRand *rand)
|
||||
{
|
||||
rand->lock.Lock();
|
||||
AU_LOCK_GUARD(rand->lock);
|
||||
AuUInt32 ret = WELL_NextLong_Unlocked(rand);
|
||||
rand->lock.Unlock();
|
||||
return ret;
|
||||
}
|
||||
|
||||
@ -95,8 +94,8 @@ void WELL_NextBytes(WELLRand *rand, void *in, AuUInt32 length)
|
||||
|
||||
i = 0;
|
||||
base = reinterpret_cast<AuUInt8 *>(in);
|
||||
|
||||
rand->lock.Lock();
|
||||
|
||||
AU_LOCK_GUARD(rand->lock);
|
||||
|
||||
for (; i < length; i += 4)
|
||||
{
|
||||
@ -110,6 +109,4 @@ void WELL_NextBytes(WELLRand *rand, void *in, AuUInt32 length)
|
||||
AuUInt32 padRng = WELL_NextLong_Unlocked(rand);
|
||||
AuMemcpy(base + i, &padRng, length - i);
|
||||
}
|
||||
|
||||
rand->lock.Unlock();
|
||||
}
|
@ -50,7 +50,7 @@ AuUInt32 MT_NextLong(MTRand *rand)
|
||||
AuUInt32 y;
|
||||
static const AuUInt32 mag[2] = {0x0, 0x9908b0df}; /* mag[x] = x * 0x9908b0df for x = 0,1 */
|
||||
|
||||
rand->lock.Lock();
|
||||
AU_LOCK_GUARD(rand->lock);
|
||||
|
||||
if (rand->index >= STATE_VECTOR_LENGTH || rand->index < 0)
|
||||
{
|
||||
@ -85,6 +85,5 @@ AuUInt32 MT_NextLong(MTRand *rand)
|
||||
y ^= (y << 15) & TEMPERING_MASK_C;
|
||||
y ^= (y >> 18);
|
||||
|
||||
rand->lock.Unlock();
|
||||
return y;
|
||||
}
|
76
readme.md
76
readme.md
@ -2,11 +2,13 @@
|
||||
|
||||
## AuroraRuntime
|
||||
|
||||
The Aurora Runtime is an platform abstraction layer for cross-platform C++ development targeting<br>
|
||||
embedded and PC systems. Simply fetch a binary package for your toolchain or integrate the build<br>
|
||||
scripts into your applications build pipeline to get started. <br>
|
||||
![picture](https://gitea.reece.sx/AuroraSupport/AuroraRuntime/raw/branch/master/Media/Hello%20Aurora.png)
|
||||
|
||||
View this raw file for improved formatting
|
||||
The Aurora Runtime is an platform abstraction layer for cross-platform C++ development targeting
|
||||
embedded and PC systems. Simply fetch a binary package for your toolchain or integrate the build
|
||||
scripts into your applications build pipeline to get started.
|
||||
|
||||
View this file without markdown for improved formatting
|
||||
|
||||
## Features
|
||||
|
||||
@ -48,29 +50,33 @@ Aurora Overloadable Type Declerations: https://git.reece.sx/AuroraSupport/Aurora
|
||||
~~Aurora Runtime does not attempt to implement your favourite production logger. We instead <br>
|
||||
implement a subscription based log message dispatcher with some default backends including <br>
|
||||
a file logger, Windows debug logging, Windows conhost stdin/out using UTF-8, UNIX stdin/out <br>
|
||||
respecting the applications codepage, a wxWidgets toolkit GUI, and hopefully more to come. ~~ <br>
|
||||
respecting the applications codepage, a wxWidgets toolkit GUI, and hopefully more to come~~<br>
|
||||
|
||||
|
||||
Additionally, consoles that provide an input stream can be used in conjunction with the parse <br>
|
||||
subsystem to provide basic command-based deserialization, tokenization, and dispatch of UTF-8 <br>
|
||||
Additionally, consoles that provide an input stream can be used in conjunction with the parse
|
||||
subsystem to provide basic command-based deserialization, tokenization, and dispatch of UTF-8
|
||||
translated strings regardless of the system locale
|
||||
|
||||
## Exceptions
|
||||
|
||||
Through the use of compiler internal overloads, ELF hooking, and Win32 `AddVectoredExceptionHandler`, Aurora <br>
|
||||
Runtime hooks exceptions at the time of throw, including *some* out of ecosystem exceptions, providing detailed <br>
|
||||
telemetry of the object type, object string, and backtrace. In addition, the `AuDebug` namespace provides TLS based <br>
|
||||
last-error and last-backtrace methods. <br>
|
||||
Through the use of compiler internal overloads, ELF hooking, and Win32
|
||||
`AddVectoredExceptionHandler`, Aurora Runtime hooks exceptions at the time of throw, including
|
||||
*some* out of ecosystem exceptions, providing detailed telemetry of the object type, object
|
||||
string, and backtrace. In addition, the `AuDebug` namespace provides TLS based last-error and
|
||||
last-backtrace methods. <br>
|
||||
|
||||
EXCEPTIONS ARE NOT CONTROL FLOW...<br>
|
||||
- Aurora Runtime WILL attempt to mitigate exceptions in internal logic
|
||||
- Aurora Runtime WILL NOT abuse exceptions to communicate failure
|
||||
- Aurora Runtime WILL try to decouple internal exceptions from the API
|
||||
- Aurora Runtime WILL NOT use anything that automatically crashes on exception catch (no-nothrow)
|
||||
- Aurora Runtime WILL provide extended exception information to telemetry backends and through the `AuDebug` namespace
|
||||
- Aurora Runtime WILL NOT make any guarantees of being globally-nothrow; however, it should be a safe assumption in non-critical environments
|
||||
- Aurora Runtime WILL provide extended exception information to telemetry backends and through
|
||||
the `AuDebug` namespace
|
||||
- Aurora Runtime WILL NOT make any guarantees of being globally-nothrow; however, it should be a
|
||||
safe assumption in non-critical environments
|
||||
|
||||
`SysPanic` can be used to format a `std::terminate`-like exit condition, complete with telemetry data and safe cleanup.
|
||||
`SysPanic` can be used to format a `std::terminate`-like exit condition, complete with telemetry
|
||||
data and safe cleanup.
|
||||
|
||||
|
||||
## Loop
|
||||
@ -167,31 +173,31 @@ User-overloadable type declerations and generic access utilities are defined und
|
||||
|
||||
## Binding
|
||||
|
||||
Aurora Runtime provides C++ APIs; however, it should be noted that two libraries are used to extend interfaces and enums <br>
|
||||
to help with porting and internal utility access. One, AuroraEnums, wraps basic enumerations and provides value vectors; <br>
|
||||
value strings; look up; iteration; and more. The other, AuroraInterfaces, provides *TWO* class types for each virtual interface. <br>
|
||||
Each interface can be backed by a; C++ class method overriding a superclass's `virtual ...(...) = 0;` method, or a `AuFunctional`<br>
|
||||
-based structure. <br>
|
||||
Aurora Runtime provides C++ APIs; however, it should be noted that two libraries are used to extend interfaces and enums
|
||||
to help with porting and internal utility access. One, AuroraEnums, wraps basic enumerations and provides value vectors;
|
||||
value strings; look up; iteration; and more. The other, AuroraInterfaces, provides *TWO* class types for each virtual interface.
|
||||
Each interface can be backed by a; C++ class method overriding a superclass's `virtual ...(...) = 0;` method, or a `AuFunctional`
|
||||
-based structure.
|
||||
|
||||
It should be noted that most language bindings and generator libraries (^swig, v8pp, nbind, luabind) work with shared pointers. <br>
|
||||
Other user code may wish to stuff pointers into a machineword-sized space, whether its a C library, a FFI, or a size constraint. <br>
|
||||
One handle or abstraction layer will be required to integrate the C++ API into the destination platform, and assuming we have a <br>
|
||||
C++ language frontend parsing our API, we can use `AuSPtr` for all caller-to-method constant reference scanerios. <br>
|
||||
Furthermore, `AuSPtrs` can be created, without a deletor, using `AuUnsafeRaiiToShared(unique/raw pointer)`. To solve the raw <br>
|
||||
pointer issue, `AuSPtrs` are created in the public headers with the help of exported/default visibility interface create and <br>
|
||||
destroy functions. These APIs provide raw pointers to public C++ interfaces, and as such, can be binded using virtually any <br>
|
||||
shim generator. Method and API mapping will likely involve manual work from the library developer to reimplement AU concepts <br>
|
||||
under their language runtime instead of using the C++ platform, or at least require manual effort to shim or map each runtime <br>
|
||||
prototype into something more sane across the language barrier. <br>
|
||||
It should be noted that most language bindings and generator libraries (^swig, v8pp, nbind, luabind) work with shared pointers.
|
||||
Other user code may wish to stuff pointers into a machineword-sized space, whether its a C library, a FFI, or a size constraint.
|
||||
One handle or abstraction layer will be required to integrate the C++ API into the destination platform, and assuming we have a
|
||||
C++ language frontend parsing our API, we can use `AuSPtr` for all caller-to-method constant reference scanerios.
|
||||
Furthermore, `AuSPtrs` can be created, without a deletor, using `AuUnsafeRaiiToShared(unique/raw pointer)`. To solve the raw
|
||||
pointer issue, `AuSPtrs` are created in the public headers with the help of exported/default visibility interface create and
|
||||
destroy functions. These APIs provide raw pointers to public C++ interfaces, and as such, can be binded using virtually any
|
||||
shim generator. Method and API mapping will likely involve manual work from the library developer to reimplement AU concepts
|
||||
under their language runtime instead of using the C++ platform, or at least require manual effort to shim or map each runtime
|
||||
prototype into something more sane across the language barrier.
|
||||
|
||||
Memory is generally viewed through a `std::span` like concept called MemoryViews. `MemoryViewRead` and `MemoryViewWrite` <br>
|
||||
provide windows into a defined address range. `MemoryViewStreamRead` and `MemoryViewStreamWrite` expand upon this concept by <br>
|
||||
accepting an additional offset (`AuUInt &: reference`) that is used by internal APIs to indicate how many bytes were written or <br>
|
||||
read from a given input region. Such requirement came about from so many APIs, networking, compression, encoding, doing the exact <br>
|
||||
Memory is generally viewed through a `std::span` like concept called MemoryViews. `MemoryViewRead` and `MemoryViewWrite`
|
||||
provide windows into a defined address range. `MemoryViewStreamRead` and `MemoryViewStreamWrite` expand upon this concept by
|
||||
accepting an additional offset (`AuUInt &: reference`) that is used by internal APIs to indicate how many bytes were written or
|
||||
read from a given input region. Such requirement came about from so many APIs, networking, compression, encoding, doing the exact
|
||||
same thing in different not-so-portable ways. Unifying memory access to 4 class types should aid with SWIG prototyping.
|
||||
|
||||
Unrelated note, structure interfacing with questionable C++ ABI reimplementations is somewhat sketchy in FFI projects (^ CppSharp)<br>
|
||||
can lead to some memory leaks. <br>
|
||||
Unrelated note, structure interfacing with questionable C++ ABI reimplementations is somewhat sketchy in FFI projects (^ CppSharp)
|
||||
can lead to some memory leaks.
|
||||
|
||||
|
||||
## IO
|
||||
|
Loading…
Reference in New Issue
Block a user