[EMAIL PROTECTED] writes:
> I am trying to add hardware handshaking to the RXTX package and am
> having lots of troubles with the java environment. I have a routine in C
> that handles hardware handshaking without any problems. However,
> incorporating this routine into java with JNI causes all sorts of
> strange problem. i.e a call to tcgetattr works immediately after turning
> h/w handshaking off, however when this routine is called again I get an
> IO error on the tcgetattr call, just trying to read the damn status!
> Somehow jumping fro the C code back into java and back again stuffs up
> the port somehow. Anyone have any ideas ????
>
> What the hell does the java do to the machine since I can't even open a
> port non_blocking under java!!
The ports are already nonblocking! Greeen threads makes every file descriptor
that gets created be put into nonblocking mode. It does this by interposing on
system calls like open, and forcing the fd to be attributed appropriately
(i.e. nonblocking, and registered with the interrupt system so that SIGIO's
are delivered).
You have basically two choices:
a) Ignore trying to make the fd nonblocking.
b) (preferred) -- use the "internal" libc open() call (__open) yourself.
same for read, write, select, and some others that I don't think
are relevant. If you can #define open in your code to be __open, and
similarly for the other system calls that you need to issue (to be
on the safe side, I think you could #define all system and c library
calls that you make to be the __ variant).
Steve
