[LAD] Looking for an introduction to rt programming with a gui

torbenh torbenh at gmx.de
Sat May 22 11:06:23 UTC 2010


On Fri, May 21, 2010 at 11:01:44PM +0200, Arnout Engelen wrote:
> On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote:
> > On Fri, May 21, 2010 at 8:33 AM, torbenh <torbenh at gmx.de> wrote:
> > > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> > > > "hard realtime" often precludes the use of Garbage collectors. Of 
> > > > course Java has RT garbage collectors available:
> > > > http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/
> > >
> > > Java RTS has an innovative pricing model that starts at $6500 per
> > > socket/CPU for development or internal deployment.
> > >
> > > well... thanks :S
> > 
> > Java is open source. 
> 
> Well, indeed a big part of the Sun JVM has been open-sourced under the name 
> 'OpenJDK'. That does not mean the Java RTS is open-sourced - I'm pretty
> sure it isn't. But I'm not even sure RTS provides the kind of RT we're looking
> for in the LAD world.

that statement about the pricing model was a quote from the java RTS
FAQ.
opensourcing something of that price would be a bit dumb :)

> 
> > There are people using embedded and sometimes RT java,
> > to varying degrees of effectiveness, in all sorts of everyday devices, like
> > your cable company-provided DVR and set top box (which I've worked on) and
> > sometimes  even your credit card verification devices (which i've also
> > worked on).
> 
> What kind of 'real time' are we talking about here, exactly? I think the 
> definition relevant for the LAD world is basically: "it can be guaranteed that
> no non-RT-safe calls (like anything that may block, including malloc) will 
> take place while handling the JACK process() callback". 
> 
> Can OpenJDK provide that guarantee? This never has been quite clear to me.

i doubt it can.

> 
> The JACK thread can be run at a higher priority than the other Java process
> threads (including the GC thread), so as long as there's no non-RT-safe calls
> I think we should be safe from being interrupted by the GC (right?). Probably
> the jack process() callback would call some Java code though JNI (like JJack[1]
> does). *If* JNI doesn't do anything non-RT-safe, and *if* it is possible to 
> avoid doing non-RT-safe stuff at the Java side (by adhering to some rules in 
> your Java code, much like you'll have to do when writing C code), it'd be 
> possible to write RT-safe code in Java.

there is another if:
*if* the jvm can guarantee me that it will only execute jit compiled
code in my process callback. without such a guarantee the whole jit
compiler is irelevant, since we are only interested in maximum
execution times.

> 
> It sounds possible, but there are some big 'ifs' there.
> 
> Of course the more interesting features of Java would probably still be 
> forbidden to be used in the JACK process() callback.
> 
> > > i dont understand... are you seriously arguing that dynamic languages
> > > are always better ?
> > 
> > No! (...) However programming in those languages, prototyping UI's in those 
> > languages is really tedious. Changing and updating and adapting applications
> > for new uses is very frustrating in those environments.
> 
> I tend to disagree: actually I find changing/updating/adapting things in a 
> dynamic language is more frustrating and tedious because there's no compiler 
> to tell me which bits I missed. But perhaps we shouldn't rehash the old static
> vs dynamic typing debate here ;).

no we shouldnt.
thats pretty much the point i was referring to.
for just quick prototypes dynamic languages are naturally better.


-- 
torben Hohn



More information about the Linux-audio-dev mailing list