From: Daniel Veillard (Daniel.Veillard@w3.org)
Date: Tue Sep 08 1998 - 15:41:04 EDT
Hi Godmar,
> I don't think there's anything that would prevent us from adding
> fixfd again. This might be useful for the case where you inherit
> fd's from X, because you can't make X use the jsyscall function needed
> to create the descriptor (which would be the "right" way of doing it).
> As for pipes, wouldn't it make more sense to add a pipe() call to the
> jsyscall interface?
Well, on the other hand for portability it's probably better to give
a way to register/unregister FD than to try to add a wrapper for any
function in any OS which create a FD ...
> I see a related problem in EventQueue.getNextEvent in the X11-based AWT.
> There, the thread polls for events at a given rate, which clearly seems
> suboptimal. The reason it needs to poll is because even if it could
> "fixfd" the file descriptor associated with the X11 connection, it
> couldn't get Xlib to use jsyscall's "read".
Basically we have the same kind of problems there. The big picture
in Amaya is that Amaya runs as a Kaffe thread, but still relies on X-Windows
and Motif calls to fetch events. The main loop is took off both Amaya and
Kaffe and implemented in a separate module which tries to make them work
in good harmony (that's difficult since sometimes new threads created by
HTTP requests - done in Java - need user interraction for example during
authentification dialogs and you get two threads competing for X events).
> What are the alternatives? I looked some at X11's public header files,
> but there doesn't seem to be a way for X11 to "import" a read method.
> I think what would be needed would be to replace the "transport"
> (I think that what they call it) for that XConnection. This, however,
> seems to require the use of X11-internal header files; and it also might
> not work well with optimizations such as Xshm.
> You know more about this than I do: is this a correct assessment?
I remember seing Java implementation of the Xlib, but you're right this
certainly destroys Xshm ...
> We should also keep in mind that we don't want to preclude
> a native win32 port, so our jsyscall interface should to a certain
> degree reflect that.
That's why I think that adding/removing FD is cleaner than adding
new syscall wrappers. For the AWT implementation I don't know much
about Windows envent loop except that it's probably quite easier
to build cleanly a threaded app.
> Also, when you say that Amaya still manages the internal select call,
> do you mean that Xlib manages it or do you have a separate layer in
> Amaya that does that? If the latter, would it maybe make sense to
> use Kaffe's syscall layer instead (given that it is sufficient for
> the task, possibly after modifying it?)
The second as explained above. I'm wondering wether I should really
try to get the syscall layer changed to fit better with the current
way I did the glue or to change the glue code to rely more on Java
code and give back the main loop to Kaffe.
If I was able from Java code to detect wether there is an X-Window
event waiting then things would be quite simpler since I would do all
the synchronization stuff in Java, and just call C to fetch and handle
the event. This code would also be less dependant on Kaffe internal
which is good since I would have less work keeping up with kaffe
developement.
Daniel
-- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:55 EDT