[Xenomai-core] Ambiguity in description about rt_task_delete()
Hi, I just stumbled across an ambiguity in the documentation for rt_task_delete() in the native skin. One could think that this function can only be called from userspace if it is a RT task because of This service can be called from: ... User-space task (switches to primary mode) But this is only true if the argument is NULL. Otherwise it is possible from NRT context (if I understood the code in task.c correctly). Maybe a clearer description is necessary here. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RT pipes
Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Ambiguity in description about rt_task_delete()
Hi, I just stumbled across an ambiguity in the documentation for rt_task_delete() in the native skin. One could think that this function can only be called from userspace if it is a RT task because of This service can be called from: ... User-space task (switches to primary mode) But this is only true if the argument is NULL. Otherwise it is possible from NRT context (if I understood the code in task.c correctly). Maybe a clearer description is necessary here. Sebastian
[Xenomai-core] RT pipes
Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. Sebastian
Re: [Xenomai-core] RT pipes
Sebastian Smolorz wrote: Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? Nope. If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. ioctl(fd,XNPIPEIOC_FLUSH,0) would do, but still, we should clear the output queue when closing the kernel side. In the same vein, closing the user-space side does not clear the input queue that feeds the kernel side. Thanks for spotting this. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] RT pipes
Philippe Gerum wrote: Sebastian Smolorz wrote: Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? Nope. If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. ioctl(fd,XNPIPEIOC_FLUSH,0) would do, but still, we should clear the output queue when closing the kernel side. In the same vein, closing the user-space side does not clear the input queue that feeds the kernel side. Thanks for spotting this. Ok, fixed. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] RT pipes
On Wed, 9 Nov 2005, Philippe Gerum wrote: Philippe Gerum wrote: Sebastian Smolorz wrote: Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? Nope. If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. ioctl(fd,XNPIPEIOC_FLUSH,0) would do, but still, we should clear the output queue when closing the kernel side. In the same vein, closing the user-space side does not clear the input queue that feeds the kernel side. Thanks for spotting this. Ok, fixed. Thanks, now it works! :-) Sebastian
