Well - anything you do with native code in Java is inherently "dangerous".In a sense yes, but trying to do direct system lib access, while on the same time the green threads lib does its magic makes it suicidial.
Although it might even work, I wouldn't put much trust on it - except if I were one of the green threads lib authors :-)
Obviously it's best to use native threads when doing this kind of thing,
but I want compatibility with green threads in case people need that.
I am not talking about breaking compatibility with green threads.
I am talking about detecting the vm type at runtime and setting up the
environment accordingly.
e.g (qnd, but you get the point):
interface fdset {
// ...
Socket select();
interface Factory {
fdset create();
}
public static final Factory factory = (Factory)Environment.createInstance(
"fac1", "fac2" );
}
and sth like
class Environment {
public static Object createInstance( String green,
String native ) {
if ( System.getProperty(
"java.vm.info" ).indexOf( "green" ) < 0 )
return Class.forName( native ).newInstance();
else
return Class.forName( green ).newInstance();
// Let's ignore exceptions...
}
}
and perhaps use like :
fdset myfdset = fdset.factory.create();
myfdset.add( mysocket1);
// ... add some sockets or fd's to the fdset
Socket ready = myfdset.select(); // etc...
So, all you have to do, is provide a seperate thread-based implementation (the usual thread-pool, message queue and friends mess) for green threads environment.
Now, you'll probably ask why on earth someone should do sth like this.
Well, if your lib hack proves to work there is no need, indeed. But if
not, this is a clean way of doing it. You can even dynamically specify
the factories for the various type of systems...
> Since the thread proliferation problem really affects only native threads
> vm,That's not quite true - there is still a limitation on creating a large
number of green threads to simulate nonblocking I/O. Although green threads
effectively use select() and nonblocking I/O internally, they don't seem
to scale
-- exactly why, I don't know -- probably because of things like
scheduler overhead.
Basically, the only compelling reason (apart from bugs) is
the abitlity to create a larg number of i/o devoted threads.
Green threads have real trouble with computationally intensive
tasks, which can easily hog the other threads - except if you explicitly
fill your code with yields or write your own scheduler.
So, if they fail for i/o applications - then there is no need to have
them at all.
-- dimitris mailto:[EMAIL PROTECTED]
