[Twisted-Python] Proposal: changes to reactor.clientTCP

Tommi Virtanen tv at twistedmatrix.com
Fri Jun 21 13:04:08 MDT 2002


Glyph Lefkowitz <glyph at twistedmatrix.com> writes:

> > > 	Please do not clobber the information given by the
> > >         kernel in errno. Translating errno to 2 different failures
> > >         is not nice.
> 
> > It needs to be clobbered, at least in some sense, for portability.
> > 
> > Jython does not have errno and win32's support for it is very weak.
> 
> Reading this a few hours later, I think my tone was wrong and I was altogether
> too brief here. :-).  To rephrase in a more constructive manner:
> 
> I believe that it needs to be clobbered, and some information lost, because I
> don't see any other way to retain portability.  Also, we're losing information
> already, since errno is used to report things that aren't "errors" in the
> Twisted worldview (or at least, not errors that the user can deal with
> directly).  Jython and win32 both have error-reporting mechanisms; Jython's is
> exceptions, win32 is a sort of wacked-out informal errno.  Can you think of a
> few primitive errors that we should support, rather than just the 2 types?
> (I'd rather use Failure than just integer error codes, personally.)
> 
> I think that if we're going to add a new error reporting mechanism we need to
> do it carefully so that we don't miss the same kind of information that we did
> the last time we architected this API.  (Protocol.connectionLost used to take
> an integer error code which was one of these two errors; that was a bad idea,
> too).
> 
> Thanks for your feedback.  Does anybody have a solution?

	Allow portable programs to get a "sanitized version", but
        allow my POSIX-only programs get errno. For what kind of
        sanitization one might want, you probably want to look at the
        man page for say connect(2) for all the possible error cases,
        and categorize them based on local/remote, temporary/permanent,
        etc., and create a "high-level error" for each class, with
        perhaps the string corresponding to the errno as extra info
        meant for users (and not if statements).

        But please do _not_ loose any information in the translation.
        Say people shouldn't look at the error objects errno attribute
        to decide what to do, as not all platforms provide it. But
        don't hide the actual error.

        Remember my background; I'm a kernel hacker, and I know the
        UNIX libc/kernel API. If I run a program that tries to
        e.g. connect with TCP, and it fails without giving me a good
        reason, I _will_ run it under strace -e trace=connect just to
        see whether connect failed, and with what errno. Operating
        systems without BSD sockets just aren't, and I write my
        programs to use fork anyway. My point -- don't decide for me,
        let me decide on my own.

-- 
tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
double a,b=4,c;main(){for(;++a<2e6;c-=(b=-b)/a++);printf("%f\n",c);}




More information about the Twisted-Python mailing list