[Xenomai-core] [bug] user memory leakage on rt_task_delete

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 rt_task_create/delete in a

[Xenomai-core] [patch] fix rt_task_delete for cancellable rt-threads

Hi, no, this is not the fix for the issue I described earlier. This just improves the behaviour of rt_task_delete in case the target is blocking at a cancellation point (tested with standard sem_wait). With the current version, rt_task_deletes the rt-shadow and just wakes up the linux pthread

[Xenomai-core] [doc-patch] rt_task_create user stack size

Hi, Please apply this, the statement is no longer valid. --- ksrc/skins/native/task.c(revision 243) +++ ksrc/skins/native/task.c(working copy) @@ -117,7 +117,7 @@ * * @param stksize The size of the stack (in bytes) for the new * task. If zero is passed, a reasonable pre-defined

[Xenomai-core] anonymous rt_tasks in userspace / registry dependencies

Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? 2. Doesn't render switching off XENO_OPT_NATIVE_REGISTRY the

[Xenomai-core] [patch] fix posix userspace headers

Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Index: include/posix/signal.h === --- include/posix/signal.h (Revision 245) +++ include/posix/signal.h (Arbeitskopie) @@ -20,6 +20,12

[Xenomai-core] [bug?] set pthread stack size broken

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 program one time as

[Xenomai-core] [bug] user memory leakage on rt_task_delete

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 rt_task_create/delete in a

[Xenomai-core] [patch] fix rt_task_delete for cancellable rt-threads

Hi, no, this is not the fix for the issue I described earlier. This just improves the behaviour of rt_task_delete in case the target is blocking at a cancellation point (tested with standard sem_wait). With the current version, rt_task_deletes the rt-shadow and just wakes up the linux pthread

[Xenomai-core] [doc-patch] rt_task_create user stack size

Hi, Please apply this, the statement is no longer valid. --- ksrc/skins/native/task.c(revision 243) +++ ksrc/skins/native/task.c(working copy) @@ -117,7 +117,7 @@ * * @param stksize The size of the stack (in bytes) for the new * task. If zero is passed, a reasonable pre-defined

[Xenomai-core] anonymous rt_tasks in userspace / registry dependencies

Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? 2. Doesn't render switching off XENO_OPT_NATIVE_REGISTRY the

[Xenomai-core] [patch] fix posix userspace headers

Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Index: include/posix/signal.h === --- include/posix/signal.h (Revision 245) +++ include/posix/signal.h (Arbeitskopie) @@ -20,6 +20,12