Ignacio García Pérez wrote:
Suppose I have a kernel rt task that samples data at a certain rate and
writes it as messages into a rt pipe, from which it is read by a user
space non rt program.
I want to limit the number of messages that are put into the pipe,
because otherwise if the user space program dies, it will grow endlessly
till it exausts the rt heap.
What I want to do is to have a pipe that can hold a limited number of
messages such that rt_pipe_write will fail if it is full.
Is there a way to know how many messages are there in the pipe?
Even if there is a way, to prevent a (harmless) race condition, I would
need to lock the pipe between checking the number of messages and
calling rt_pipe_write. As far as I know, pipe locking belongs to the
nucleus and I'd like to stay in the native skin as much as possible.
Another method would be to count how many messages I write, but then I'd
need some hook that notifies me when the user space program reads a
message so I can decrement the count.
The plan is to be able to tell the pipe manager to use a user-provided heap
instead of the system one; this way, exhausting the local heap (*) in RT space
would be a clear sign that non-RT must be allowed to consume the pending data
first. A simple interface to do that is missing, but the pipe manager already
works with a variable heap pointer.
(*) Using the overall available memory seems a better metric than the number of
pending messages, since it may often happen that messages have different sizes.