How does/can jthread override blocking I/O calls on LinuxVR?

[Godmar Back]

No, we don't do that.  There may be options, but they're not very portable.

There's two issues: blocking and async-signal safety.

As for blocking, we simply don't call any function that could block.
For instance, X11 first polls using a non-blocking select, and the
we get the event with whatever function does that.  At least that's the
intention.

For kaffe's native libs, there are macros KREAD, KWRITE and so on
that provide non-blocking versions.

Other native libs would either have to use those macros or risk blocking
the whole process.  Unfortunately, Sun didn't specify an API upon
which native libs can rely.

As for async-signal safety, all remaining calls to library functions 
for which there's no jthread version and which are not async-signal 
safe must be wrapped with enter/leaveSafeRegion. (they're not at
this point)

	- Godmar

> 
> 
> Hello...
> 
> As I continue to work on building Kaffe for the Agenda PDA (like
> PocketLinux, another LinuxVR platform), I've hit a point of major
> confusion: I cannot see how blocking I/O calls from external libraries,
> such as libX11.a, are replaced with corresponding calls to the jthread
> library. I thought I understood: the entire application is built
> statically linked and calls like select() and read() are "hijacked" by
> locally defined versions - but the Kaffe build does no such thing. I'm
> working with the source distributed through the PocketLinux project; is
> there some build magic I'm missing?
> 
> Nathan Meyers
> nmeyers at javalinux.net
>