[Spice-devel] spice BSD/OSX client
attila.sukosd at gmail.com
Fri Jun 25 03:32:43 PDT 2010
On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann <kraxel at redhat.com> wrote:
> 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
> 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
> Hi Gerd,
Thanks for the fast reply! Sounds good! Yes, right now I've been working on
version 0.4, but since the unstable tree is now backwards compatible, I will
move on to that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spice-devel