Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on.
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For a simple test,
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For
Follow-up for the previously posted powerpc SMP timer support code.
It's better to let each processor set its own disarm_decr. Additionally,
cuts down unused code from UP build. Tested on a G5 SMP UP.
-- Heikki Lindholm
diff -Nru xenomai.orig/ksrc/arch/powerpc/hal.c
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For a simple test, compile the attached
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For a simple test,
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For
Jan Kiszka wrote:
Hi all,
during my ongoing search for the init/cleanup issue of shadow threads, I
stumbled over another problem: Deleting a userspace native thread that
is blocked in primary mode does not let the NPTL clean up all resources
allocated in userspace. If you plan to do some
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi all,
during my ongoing search for the init/cleanup issue of shadow threads, I
stumbled over another problem: Deleting a userspace native thread that
is blocked in primary mode does not let the NPTL clean up all resources
allocated in userspace. If
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi all,
during my ongoing search for the init/cleanup issue of shadow threads, I
stumbled over another problem: Deleting a userspace native thread that
is blocked in primary mode does not let the NPTL clean up all resources
allocated
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi all,
during my ongoing search for the init/cleanup issue of shadow threads, I
stumbled over another problem: Deleting a userspace native thread that
is blocked in primary mode does not let the NPTL clean up all resources
Follow-up for the previously posted powerpc SMP timer support code.
It's better to let each processor set its own disarm_decr. Additionally,
cuts down unused code from UP build. Tested on a G5 SMP UP.
-- Heikki Lindholm
diff -Nru xenomai.orig/ksrc/arch/powerpc/hal.c
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
13 matches
Mail list logo