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.

Any ideas?

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.



Reply via email to