Philippe Gerum wrote:
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.
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
// clean up all the queues
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
"reschedule" in the Linux sense here; entering Xenomai's rescheduling procedure with the
superlock held is of course perfectly valid.
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.
Xenomai-core mailing list