From: Parmelan, Edouard (EP510777@exchange.FRANCE.NCR.com)
Date: Tue Jan 05 1999 - 12:41:18 EST
Godmar,
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.
You're right, I don't read the definition of KSELECT() and
I wrongly assumed that it only block the current thread :(
Peter, I have new Comments:
- In Component.reshap() a COMPENENT_MOVED event is send if
!sized && !moved. If I enclose it in the if (sized || moved)
block, some NativeGraphic are not sync because there are
not relative to parent Frame native window but relative to
DefaultRoot() :(
Why all native windows have DefaultRoot() as parent and
not the native window of the parent Frame ?
- Eugene O'Neil write "X Tool Collection" (www.cs.umb.edu/~eugene/XTC).
XTC is an object oriented, multi-threaded implementation of
the X Window protocol, written in pure Java.
KSELECT() problem could be removed if we implement a subset of
X Window Protocol in Java as in XTC :)
Comments ?
Edouard.
--- Edouard.Parmelan@France.NCR.COM PS: This address will be invalidate on January 27, 1999
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:30 EDT