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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
