I've changed the implementation of this fix to avoid a misinterpretation of an EINVAL return code. The solution now puts a separate try block around the connect call and catches EINVAL there, retrying the call with a non-blocking socket if it sees one.
A new webrev has been posted here: http://cr.opensolaris.org/~tmueller/cr-2695,2705-2/ Links to issues: http://defect.opensolaris.org/bz/show_bug.cgi?id=2695 http://defect.opensolaris.org/bz/show_bug.cgi?id=2705 Thanks. Tom Tom Mueller wrote: > What do you think about this way of addressing the EINVAL? > > When the EINVAL is detected, create a new socket and retry the > connection without calling settimout. If a ECONNREFUSED is received > then, return True. If the connect works, return false. For anyother > exception, including another EINVAL, reraise. > > This EINVAL detection will need to be an extra block around just the > connect call. > > Tom > > > Danek Duvall wrote: >> Thing that worries me about this particular change is that the EINVAL >> could >> mean other things, too. Perhaps we don't have to worry about invalid >> parameters being passed to the system call, but it strikes me as being >> something we wouldn't want to paper over. >> >> That said, I'm not sure I have a better answer. Do we have a way of >> distinguishing these "broken" systems so we can make an explicit check? >> >> Danek >> > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
