Matt Welsh wrote:
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 - ex
Matt Welsh wrote:
>
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
> > > "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
> >
> > Matt> Turns out this is not as easy as it could be -- because even
> > Matt> though you call system calls like read(), write(), and
> > Matt> fcntl()
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> > "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
>
> Matt> Turns out this is not as easy as it could be -- because even
> Matt> though you call system calls like read(), write(), and
> Matt> fcntl() from native code, these are tra
> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
Matt> Turns out this is not as easy as it could be -- because even
Matt> though you call system calls like read(), write(), and
Matt> fcntl() from native code, these are trapped by the Java
Matt> runtime library to do magic th
Dimitris Vyzovitis <[EMAIL PROTECTED]> writes:
>
> Isn't that a bit dangerous?
Well - anything you do with native code in Java is inherently "dangerous".
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 tha
Matt Welsh wrote:
In other words, although I was creating a nonblocking
socket and issuing
read calls against it in JNI-based C code, those system calls (from
C)
were in fact being caught by the Java runtime library which was turning
them back into "blocking" access to the socket. This is because
Our discussion on thread overheads and using nonblocking I/O in Java
strikes close to home - here at Berkeley we are building an event-driven
Internet server platform, implemented entirely in Java. Obviously for this
to work we need nonblocking I/O primitives.
So, I've been working on implement
