[Spice-devel] spice BSD/OSX client
Gerd Hoffmann
kraxel at redhat.com
Fri Jun 25 02:41:51 PDT 2010
Hi,
> Also, the kqueue implementation in OS X 10.6 seem to have been broken,
> so I went with your suggestion and reimplemented the event handler using
> select(). One thing I noticed though was that the epoll implementation
> watched the fds for both read and write (add_to_poll()), but since it is
> edge triggered, it only fires once per change, but my select()
> implementation is level triggered, which meant it would never block and
> use up 100% CPU (for example monitoring a File fd, it always triggers).
> After playing a bit around with it, i decided to drop watching write for
> fds all together, and the client seem to work fine. Is there a need to
> check it or am I safe with monitoring only reads?
It isn't save. When you got -EAGAIN from a write() or send() syscall
because the output pipe is full you have to watch for the socket
becoming writable so you can flush out the bits you havn't sent yet.
As far I know there is no bulk data going from client to server, so if
you are working on a fast LAN it is quite possible that you never hit
the "output pipe full" case and the client works fine for you.
> Now on to the audio, I have been implementing audio using CoreAudio
> Framework for OS X (another idea could be OpenAL which is also
> cross-platform?), which pulls in a lot of extra headers, including
> MacTypes.h which unfortunately defines a "Rect" and "Point" struct which
> causes issues with the definitions inside common/draw.h. I can hack
> around it, but its not very nice, or I could rename the ones in spice,
> but that would break any compatibility with my patches to the current
> upstream code.
What code base you are working on? In the unstable tree the structs
have been renamed to SpiceRect and SpicePoint exactly to avoid name
clashes like this. Also the headers have been splitted away into a
spice-protocol package.
A few days ago Alex landed the marshaller bits in the unstable tree and
the spice client can handle both 0.4 and unstable spice protocols now.
So you can jump to the unstable code base even if you need the client
play nicely with 0.4 spice servers. This will also make it easier to
merge your patches upstream.
HTH,
Gerd
More information about the Spice-devel
mailing list