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?
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.
---
Dmitry
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
