On Thu, Jun 22, 2000 at 03:29:23PM +0100, Stuart Hughes wrote:
> What is a good complaint ??? doesn't the 'P' in POSIX stand for portable
> ? What you continually offer is non-portable extensions that make it
> impossible to run the same code on any environment other than RTLinux.  

Continually? Really, the API has been pretty dull for nearly a year.
But RTLinux _is_ different than other environments.  

> A better idea might be to use what exists so that we all have a chance
> of running our code on a number of operating systems.  May I suggest
> that a SIGHUP may be construed as a wakeup signal to a thread (it has
> been used context before), this may be bogus too, but you get the idea:
> try to use something that has a chance of being portable. 

SIGHUP is fine. Actually, WAKEUP is defined as 1 so SIGHUP will
do the same thing. I'm not sure if it is better, however, to pretend that
we are doing something you can do in Chorus or PSOS. After all, you 
are sending an interrupt from the RTkernel to a Linux subthread and this
is not something that "exists" or can be done on other operating systems.

We've had this discussion before and I remain convinced (under the
delusion?) that there are two different needs:

1. Pedal to metal, simple and appropriate APIs for RTLinux specific
   code: for this I like our LightWeight POSIX PThreads. Needs some
   fleshing out, but the technical soundness and coherency seem to 
   me to have been proven out.
2. Compatibility libraries that make it easy to move code from 
   legacy operating systems. 

What I most definitely do not want to do is to re-discover all the
errors and ugliness in Chorus that made me want to have RTLinux 
in the first place. I realize that people who have huge Chorus or
PSOS or ... programs will find it inconvenient that RTLinux native
programs, designed using our idea of decoupling RT and non-RT will
greatly outperform their code, but my theory is that the RTLinux
approach to RT is fundamentally _better_ than prior programming
models and I don't see any way to magically repair the damage created
by mixing RT with non-RT in one incoherent mass of code.



-- 
---------------------------------------------------------
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/

Reply via email to