[Twisted-Python] Foolscap-0.1.1 released
warner at lothar.com
Fri Apr 13 01:22:44 EDT 2007
kgi <iacovou at gmail.com> writes:
> Thanks for the latest release; Foolscap is turning out to be very powerful
> and pleasant to use. I appreciate all your work.
> 1. I'm trying to create an UnauthenticatedTub that listens on a
> system-assigned port (that is, on "tcp:0"). (I do this because I pass the
> underlying Referenceable to a remote server, and the random port is just a
> convenience to assist in debugging).
> tub = UnauthenticatedTub()
> l = tub.listenOn("tcp:0")
> tub.setLocation("localhost:%d" % l.getPortnum() )
> url = tub.registerReference(myserver, "my-service")
> print "the object is available at:", url
> However, when code like this runs, it falls foul of the "assert
> self.s.running" at pb.py:73 (in getPortnum()).
> This seems to imply that the reactor needs to be running before we can
> actually assign a port, so we can't call setLocation() or
> registerReference() until this is done.
Close.. it requires that the Tub has been started, which is a slightly weaker
requirement than the reactor being running. If you rearrange the order of
operations to do:
tub = UnauthenticatedTub()
l = tub.listenOn("tcp:0")
tub.setLocation("localhost:%d" % l.getPortnum() )
url = tub.registerReference(myserver, "my-service")
print "the object is available at:", url
Then you should find that it starts working ok.
Port numbers are allocated as soon as the Tub service is started, and isn't
"slow" (in the sense that it requires multiple turns of the reactor to
complete). The Tub is not supposed to do any network IO until it is started,
so it won't allocate the port until that point, but it doesn't really need to
(incidentally, if you need to know when the reactor has started for other
reasons, you can use reactor.callWhenRunning(cb))
The current version of Foolscap doesn't quite honor this "don't start until I
tell you to" rule: if you do getReference() before startService(), it will
cheerfully initiate outbound network connections anyways. This will be fixed
at some point.
> 2. I sent an email a while back about a possible bug I found; the archived
> version is here:
Yeah, sorry about not responding to that.. things got busy that month :).
(to be honest there are probably a number of issues with Copyable, as I
haven't personally used it nearly as much as the rest of Foolscap.)
Reading over your note, I think your analysis is exactly right.
Copyable.slice() is obligated to set self.streamable before any child objects
might get seralized, which means before the first yield(). I'll fix this
tonight. I wonder why the unit tests didn't catch it..
More information about the Twisted-Python