On 2011-03-09 11:06, Corentin Chary wrote: >> Probably the best way is to make vnc stop fiddling with >> qemu_set_fd_handler2, specifically in threaded mode. >> Why does it need to set/reset the write handler all the time? > > I didn't write the original code, but it's probably to avoid calling a > write handler when there is no data to write. That would make select() > busy loop when there are actually no data to write. > There is also the vnc_disconnect_start() case when the socket seems to > be broken and we remove all handlers. > >> The other question is: Who's responsible for writing to the client >> socket in threaded mode? Only the vnc thread(s), or also other qemu >> threads? In the former case, just avoid setting a write handler at all. > > Cheap stuff is done by the main thread (cursor, etc...). The thread > only do framebuffer updates. And both are synchronized with a vnc-private lock only? The problem with this model is the non-threaded qemu execution model. Even if we acquire the global mutex to protect handler updates against the main select loop, this won't help here. So vnc-threading likely needs to be made dependent on --enable-io-thread. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
