Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a case,
for a new client old messages are just irrelevant. And xnpipe_release()
cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and xnpipe_close_handler() be called
without holding a lock?
Yes, it on purpose. I know this make things a bit trickier since this breaks the overall
atomicity of the caller, but open/close hooks are expected to initiate/finalize
communication sessions, and that may take an unbounded amount of time, so we definitely
don't want to do this with the superlock being held.
they are not used currently so I can't see.
I intend to make xnpipe_open() completely atomic.
2) the cleaning of the queues (inq, outq) must take place atomically at
the time when XNPIPE_USER_CONN is dropped.
it's about something like
lock();
__clrbits(state->status,XNPIPE_USER_CONN);
// clean up all the queues
unlock();
it looks like we can't make the whole xnpipe_release() atomic because of
PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.
You must _never_ _ever_ reschedule with the nucleus lock held; this is a major cause of
jittery I recently stumbled upon that was induced by xnpipe_read_wait() at that time. So
indeed, xnpipe_release() cannot be made atomic this way under a fully preemptible kernel.
---
Dmitry
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
