Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79878 --- shadow/79878 2006-11-23 12:17:07.000000000 -0500 +++ shadow/79878.tmp.26600 2007-01-17 06:19:34.000000000 -0500 @@ -87,6 +87,25 @@ Created an attachment (id=18043) Test case for bug as described above. ------- Additional Comments From [EMAIL PROTECTED] 2006-11-23 12:17 ------- Fixed in svn r68399. + +------- Additional Comments From [EMAIL PROTECTED] 2007-01-17 06:19 ------- +This bug fix broke some of our tests (tests included with Ice for C# that you can find here +http://www.zeroc.com). + +Our code used non blocking Connect, Select and then GetSocketOption to figure out +whether or not the connection attempt succeeded and if not, retrieve the socket error. This +works fine on Windows with .NET but doesn't work anymore with Mono since this fix +because the mono implementation of Select()/Poll() now calls GetSocketOption which in +turns clears the socket error... (so when I call GetSocketOption it now always returns 0). +I've workaround the problem by using BeingConnect/EndConnect instead. + +I would be better if the Select()/Poll() implementation didn't call GetSocketOption so that +it's still available to the user code though. Perhaps you can use one of the techniques +described here http://cr.yp.to/docs/connect.html to figure out the connection status? + +In any case, perhaps you should consider calling GetSocketOption in the Select/Poll +implementation only if the Connected flag is false (instead of calling it all the time if the +socket is writable). _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
