Like I said before out of shear self interest I'm looking
into integrating LibGII into WINE. This has raised a few
issues.
WINE handles all its signals/select processing in a server
process. Somehow (and it's obfuscated, so I haven't figured
it out) it seems to be able to share file descriptors with the
client processes, so that even though the polling of input
file descriptors is done by the server, the actual reading
and processing of data happens direct from the file descriptor.
I could take two approaches. One would be to modify the
current libgii input drivers to all allow an fd to be passed
to them. This could be pretty tedious, and assumes that
all inputs are based on a unix file. It also sort of defeats
partially the benefits of using GII. A better tact IMO would
be to modify the WINE service loop to also poll the GII input,
and work out a mechanism for passing the events back to the
clients, even though this is a different model than what WINE
uses. I guess a third option would be to run my own
process/loop -- has anyone put any thought into a userspace
GII server/repeater daemon to serve a similar roll that GPM/X
does? I'd be interested to see it if so.
Anyway...
The wineserver service loop uses the new glibc poll(2) function.
This seems to be a convenience function on systems without
a kernel poll() call, implemented via select(), and on linux
uses the more efficient (?) kernel call. It won't integrate
neatly with giiEventSelect -- I'll have to rip the select()
emulation out of libc and use it to convert the wineserver
parameters to a select call in order to use giiEventSelect.
Alternatively, rather than doing this just for WINE, I
could provide a function e.g.
int giiEventFPoll(gii_input *inp, gii_event_mask *mask,
struct pollfd *ufds, unsigned int nfds, int time out);
...would this be a worthy addition to LibGII?
--
Brian
