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
