I am getting this error in a C++11 RTI DDS application:
worker factory's max. storage count reached (you may need to increase resource_limits.max_objects_per_thread value)
I understood from some research that this is part of the rti::core::policy::SystemResourceLimits (here). I also found some example on how to change this value in a C application but I couldn't find any example or documentation of how to do it correctly in C++11.Any pointer would be highly appreciated.
Related
I'm using append/consume buffers to reduce shading work in my path-tracer (immediately shade empty space + emitters in a pre-pass, append the remaining pixels for full processing), and I've heard that I should be using a UAV when I'm accessing through AppendStructuredBuffer<T> and an SRV when I'm accessing through ConsumeStructuredBuffer. I haven't seen that claim in any of Microsoft's documentation, but it might explain why my calls to [Consume()] are returning empty data - is it accurate?
I should have tested myself before I asked - shaders with ConsumeStructuredBuffers declared in SRV registers (tN) fail to compile and emit an error saying they're only bindable through UAVs.
My AppendStructuredBuffer bound through the UAV registers works fine, so it seems like I was just quoting hearsay; unordered-access-views should be used for both HLSL types.
Id like to use Ada with Stm32F103 uc, but here is the problem - there is no build-in runtime system within GNAT 2016. There is another cortex-m3 uc by TI RTS included - zfp-lm3s, but seems like it needs some global updates, simple change of memory size/origin doesn't work.
So, there is some questions:
Does some body have RTS for stm32f103?
Is there any good books about low-level staff of cortex-m3 or other arm uc?
PS. Using zfp-lm3s rises this error, when i try to run program via GPS:
Loading section .text, size 0x140 lma 0x0
Load failed
The STM32F series is from STMicroelectronics, not TI, so the stm32f4 might seem to be a better starting point.
In particular, the clock code in bsp/setup_pll.adb should need only minor tweaking; use STM’s STM32CubeMX tool (written in Java) to find the magic numbers to set up the clock properly.
You will also find that the assembler code used in bsp/start*.S needs simplifying/porting to the Cortex-M3 part.
My Cortex GNAT Run Time Systems project includes an Arduino Due version (also Cortex-M3), which has startup code written entirely in Ada. I don’t suppose the rest of the code would help a lot, being based on FreeRTOS - you’d have to be very very careful about memory usage.
I stumbled upon this question while looking for a zfp runtime specific to the stm32l0xx boards. It doesn't look like one exists from what I can see, but I did stumble upon this guide to creating a new runtime from AdaCore, which might help anyone stuck with the same issue:
https://blog.adacore.com/porting-the-ada-runtime-to-a-new-arm-board
It is said that on the offset 0x1C of struct PEB_LDR_DATA stores the head pointer to In InitializationOrderModuleList, is that right?
Beyond that, the second node of In InitializationOrderModuleList should be kernel32.dll, however, when I locate the second node, it turns out not to be the base address of kernel32.dll, instead, it is something like kernelbase.dll, how can that be explained?
Thanks!
You're relying on undocumented implementation details, and you ran into a newer implementation.
Implementation details aren't guaranteed to remain unchanged.
This particular detail appears to have been changed to provide defense-in-depth against code injection attacks using buffer overflow bugs.
The comments here are correct, you're running into new-ish (actually pretty old at this point) changes to Windows that dynamically load kernel32.dll. The strategy you're attempting stopped working after Vista.
That doesn't mean you can't, of course. This tactic works for me just fine:
http://blog.harmonysecurity.com/2009_06_01_archive.html
Recently I read the source of leveldb, the source url is https://leveldb.googlecode.com/files/leveldb-1.13.0.tar.gz
And when I read db/db_impl.cc,there comes the following code:
mutex_.AssertHeld()
I follow it into file port/port_posix.h,and I find the following :
void AssertHeld() { }
Then I grep in the souce dir,but can't find anyother implementation of the AssertHeld() anymore.
So here is my question,what does the mutex_.AssertHeld() do in db/db_impl.cc? THX
As you have observed it does nothing in the default implementation. The function seems to be a placeholder for checking whether a particular thread holds a mutex and optionally abort if it doesn't. This would be equivalent to the normal asserts we use for variables but applied on mutexes.
I think the reason it is not implemented yet is we don't have an equivalent light weight function to assert whether a thread holds a lock in pthread_mutex_t used in the default implementation. Some platforms which has that capability could fill this implementation as part of porting process. Searching online I did find some implementation for this function in the windows port of leveldb. I can see one way to implement it using a wrapper class over pthread_mutex_t and setting some sort of a thread id variable to indicate which thread(s) currently holds the mutex, but it will have to be carefully implemented given the race conditions that can arise.
I'm working on a boot loader on an x86 machine.
When the BIOS copies the contents of the MBR to 0x7c00 and jumps to that address, is there a standard meaning to the contents of the registers? Do the registers have standard values?
I know that the segment registers are typically set to 0, but will sometimes be 0x7c0. What about the other hardware registers?
This early execution environment is highly implementation defined, meaning the implementation of your particular BIOS. Never make any assumptions on the contents of registers. They might be initialized to 0, but they might contain a random value just as well.
from the OS dev Wiki, which is where I get information when I'm playing with my toy OS's
Best option would be to assume nothing. If they have meaning, you will find that from the other side when you need the information they provide.
Undefined, I believe? I think it depends on the mainboard and CPU, and should be treated as random for your own good.
Safest bet is to assume undefined.
Always assume undefined, otherwise you'll hit bad problems if you ever try to port architectures.
There is nothing quite like the pain of porting code that assumes everything uninitialized will be set to zero.
The only thing that I know to be well defined is the processor state immediately after reset.
For the record you can find that in Intel's Software Developer's Manual Vol 3 chapter 8: "PROCESSOR MANAGEMENT AND INITIALIZATION" in the table titled " IA-32 Processor States Following Power-up, Reset, or INIT"
You can always initialize them yourself to start with a known state.