On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
> 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 > > 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. Rgrds, Attila
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
