On Sat, Jul 15, 2000 at 11:03:29AM +0200, Herman Bruyninckx wrote:
> - A `feature' like ``If a fifo that does not exist already is opened,
> it is created with a 1K buffer'' carries IMHO the danger that is
> found all over the place in so-called ``user friendly'' software:
> the fact that the fifo does not exist already and the user tries to
> access it nevertheless looks (to me at least) very much like a
> programming error from the user, and ``hiding'' this error from the
> user by not telling him and using a default _will_ give problems
> later on (which will be _much_ more difficult to trace...).
>
> - Moreover, the 1K default is another source of potential errors: for
> example, a user writes a first program, using a fifo created by default
> and the buffer size doesn't create problems _for that particular_
> program. He thinks ``waw, nice feature, doesn't have to bother about
> fifos ever again'', and the next time he writes another program
> (needing much more than a 1K buffer!) and oops, program doesn't work
> anymore...
>
> - as a user the most ``user friendly'' thing I can imagine is _one single_
> well defined and well documented and unambiguous way to work with a
> given concept (i.c. fifos)... I don't know how this is solvable in
> the RTL-RTAI world ;-) Through the ``common API'' initiative perhaps?
rtfifos were designed to be simple and unambiguous, but perhaps they are too
limited for some uses. Our approach has been to (1) retain the original API
and semantics for compatibility and (B) try to make sure that any extensions or
additions are both necessessary and internally coherent. The motivation for the
"lightweight POSIX threads" approach we have taken is to be able to move past the
limitations of the original API while keeping things minimal and at the same time
having an API that is something more than a collection of unrelated extensions.
My original theory was that we didn't need any IPC api in RTLinux at all beyond
rtfifos since
RT threads live in a shared address space. I've had to modify that theory mainly
because we found
too many incompatible hand made ipcs were making programing complicated. But I retain
my
prejudice that any additional "feature" is guilty of bloat until proved otherwise --
I have
endless arguments with Michael about this and it is my hope that the result of our
arguments is
a reasonable compromise.
Of course, if people write RTLinux compatible packages that have extra features, then
that
increases the choices available to users.
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [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/
