If this is a loop waiting for something to happen... why not do X loops at relatively rapid succession and after loop count hits X then incrementally make it slower and slower (since things obviously arent working out or taking too long) and when loop count hits Y either stabilize the loop speed at a less aggressive rate and if things really really truly is not working out... at some point give up and clean up.
This keeps responsiveness high when everything is working fine and keeps things from going bananas when things aren't going quite as one would wish for... On 01/22/2014 10:36 PM, Orion Poplawski wrote: > With libssh 0.6.0, x2goclient consumes 100% cpu on connection. The trigger > for this is that ssh_select() was rewritten to use poll() instead of select(). > poll() has a timeout in milliseconds, select() in microseconds. x2goclient > requests a timeout of 500 microseconds which is getting rounded down to a > timeout of 0 milliseconds for poll(). > > However, this still seems to point to some poor coding on the part of > x2goclient that we're using such short timeouts. Why can't we just wait > forever in ssh_select() in SshMasterConnection::channelLoop() ? > _______________________________________________ X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
