On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote:
> Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> > > > Let's say I have N message buffers in a pool. What if
> > > > there is no more free buffer?
> > >
> > > Then the design for your hard real
> > > time system was wrong :-)
> >
> > Or system reached its limits.
>
> Yep, and the only options are a) redesign and b) upgrading the hardware.
>
> > It depends on your possibilities and intentions.
> > What if amount of incoming data is unpredictable but you have
> > to process at most as you can with a limited hardware?
>
> That's a kind of *soft* real time system, which is not really what RTL is
> intended for. (Although the input->"some kind of output" latency could have a
> hard RT requirement - but the memory allocation would still be soft RT.) You
> can't optimize a single API for both hard and soft RT, at least not without
> making it a major PITA to use if you want hard RT, so IMHO, it's a very good
> idea not to mix these two kinds of systems up when discussing APIs.
I don't think that "running out of memory" and "running out of CPU
time" are fundamentally different things. It's just that with a
memory allocator, you are notified of a lack of resources and can
do something graceful instead of locking the machine.
dave...
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
