>We have a VM for which we don't expect people to write multithreaded
>applications. Threads are can be used to deal with blocking I/O and
>co-routining, but it is not intended to be used for long running parrallel
>threads requiring scheduling.
I think you're really describing applications which have realtime
characteristics; in essence the need to offer guarantees. If you want
those guarantees then it's no good relying on Java alone; you need to
specify both Java and a given OS with appropriate realtime characteristics.
Surely that's what the Realtime Java spec is all about ? Hence some
combinations of JVM and OS will be able to meet the restrictions of the
realtime spec and thus offer 'realtime Java'. Most mainline JVMs won't but
that doesn't make them second class citizens. Anyone writing a realtime
program had better be fully aware of the characteristics of the platform
they are deploying on and the idea that the result will be universally
portable is a bit of a vain hope isn't it ?
Martin Trotter
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:37 EDT