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

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@email-addr-hidden> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev