#3835: Support statically allocated threads -----------------------------+------------------------------ Reporter: Sebastian Huber | Owner: Sebastian Huber Type: enhancement | Status: assigned Priority: normal | Milestone: 5.1 Component: score | Version: 5 Severity: normal | Resolution: Keywords: | Blocked By: 3838 Blocking: | -----------------------------+------------------------------
Comment (by Sebastian Huber): Replying to [comment:8 Joel Sherrill]: > Replying to [comment:6 Sebastian Huber]: > > I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread. > > I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space). > > How does this work with custom stack allocators? The availability of statically initialized threads doesn't mean that everyone has to use them. They are optional. I also have no intention to remove the custom stack allocator. What changes is that the memory area allocated for the stack is used also to contain the thread-local storage and the FP context. These memory areas are private to a thread and non- executable. I really don't know what a potential problem could be with a custom allocator. I plan to statically initialize the stacks for the idle threads and the MPCI receive server thread. They will reside in special linker sections so that a BSP or application can control the placement in memory. -- Ticket URL: <http://devel.rtems.org/ticket/3835#comment:9> RTEMS Project <http://www.rtems.org/> RTEMS Project
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs