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

[Nathan Meyers]

Godmar Back wrote:

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

OK, thanks. That blows my semi-educated guesses on why the existing LinuxVR
configurations (e115 & Helio) build fully static executables and why I can't
get to functional AWT apps on Agenda.

I have a basically working Kaffe, for non-AWT, and no joy once I try AWT - the
app starts, the usual bunch of startup X protocol happens, then the app
reaches a point of spinning the CPU with no further X protocol and no
appearance of any windows. The last couple of classes loaded were
Thread.Sleeper and InterruptedException, hence my suspicion that something was
amiss with blocking calls and jthreads.

Does this behavior sound like anything you saw bringing up Kaffe on the other
LinuxVR boxes?

Nathan Meyers
nmeyers at javalinux.net


>
>
> 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
> >