From: Godmar Back (gback@cs.utah.edu)
Date: Mon Jan 04 1999 - 13:01:27 EST
>
> Threads in natives
> In evt.c, you try to use threads in nextEvent().
> I think we could KSELECT() in place of jthreadBlockEAGAIN()
> if we remove the call to jthreadedFileDescriptor() in
> Java_java_awt_awt_Toolkit_evtInit().
>
> What does it means ?
> 1/ The ConnectionNumber() is in blocking mode.
> 2/ In nextEvent(), if there are zero event in the queue,
> wait for an event with KSELECT().
>
This code is not activated; USE_THREADED_AWT is not defined and
jthreadBlockEAGAIN only exists in Peter's tree.
jthreadBlockEAGAIN does the equivalent of read(fd, _, 0);
block a thread until fd becomes readable.
Peter and I had discussed how to avoid polling in the awt, but this
is the first time I look at his code. Judging from the comments in
the code, there seem to be some problems with approach.
I would strongly suspect that the problem comes from the fact that
the transport routines in Xlib cannot deal with a non-blocking fd.
Would it be possible to switch in and out of non-blocking mode as
you wait for events? Have you tried that, Peter?
I do not believe that Edouard's proposal of using KSELECT would work,
at least not in the way KSELECT is currently implemented.
Keep in mind that only the awt thread must be blocked until input
is available, and other threads must be able to proceed, for instance
those accepting connections on a socket.
In other words, KSELECT would have to be like handleIO in that it
includes all fds in which kaffe is interested --- basically, this is what
jthreadBlockEAGAIN does. I don't think implementing a multi-threaded
KSELECT is worth it. In fact, KSELECT should be removed from the syscall
interface for this reason: it's not supported by the current implementation.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:28 EDT