On 18 Sep 2000, Marcus Sundberg wrote:
> > 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 believe Wine uses clone(2) for that. I can't see how this would
> be possible otherwise. Should be possible to do the same with
> LibGII out of the box.
Actually, I figured it out. Check out the manpage for "unix",
the AF_UNIX type socket. It has a special datagram that allows
processes to share file descriptors -- one process sends the
datagram with an existing fd, and the other process receives a
datagram that may have a different value for the fd, but it behaves
like it's a dup() of the other process's handle.
> Using the 'save' filter and the 'file' input on a named pipe should
> do the trick just fine.
I'll check it out, thanks.
> > 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?
>
> Assuming it is implemented in a nice way I'd say yes.
Would it be worth extending it to handle multiple input objects along
with the multiple files? Yes we have the join function, and we
have a device number field in the events, but it might come in
handy for more esoteric uses/debugging. Anyway, it may be a while
before I work on that since I ended up deciding on doing a separate
server instead.
--
Brian
