Catching the failure to bind would certainly help (and should
probably be done no matter how the overall issue is addressed), but the
result of fixing just that part of the thread would be that the second
viewer either aborts due to the error (leaving the user to run the exact
same command again with different results) or the code has to loop back
around and find another port. Having confidence in the availability of
the local port going in would seem to be a better, albeit more involved,
fix...
-Eric
On Mon, 17 Jan 2011 15:03:27 -0500, Robert Goley wrote:
> Sounds like the real fix is to pay attention to the failure to bind
with the local port. I know that it displays a warning message. I do not
know if it returns an error code that is easy to capture. Instead of
using an external SSH, a solution could be to use the libssh library
like is used by the KDE project. That is one way we could ensure we
caught the result of the bind port call...
> On Jan 17, 2011 1:15 PM,
"Eric Stadtherr" wrote:
Links:
------
[1]
mailto:estadth...@gmail.com
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
