Opened 7 years ago

Last modified 15 months ago

#6606 defect new

t.i.endpoints.ProcessEndpoint doesn't work with LineReceiver because _ProcessEndpointTransport object has no attribute disconnecting

Reported by: Richard Wall Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: Wim Lewis Branch:
Author:

Description

I was trying to write an example for ProcessEndpoints:

...but got this error from LineReceiver.

[richard@zorin udp-port-from-fd-5574-3]$ python doc/core/howto/listings/process/pingbars.py example.com                                            
Unhandled Error
Traceback (most recent call last):
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/python/log.py", line 88, in callWithLogger
    return callWithContext({"system": lp}, func, *args, **kw)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/python/log.py", line 73, in callWithContext
    return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
--- <exception caught here> ---
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
    why = selectable.doRead()
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/process.py", line 257, in doRead
    return fdesc.readFromFD(self.fd, self.dataReceived)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/fdesc.py", line 94, in readFromFD
    callback(output)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/process.py", line 260, in dataReceived
    self.proc.childDataReceived(self.name, data)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/process.py", line 887, in childDataReceived
    self.proto.childDataReceived(name, data)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/internet/endpoints.py", line 336, in childDataReceived
    return self.protocol.dataReceived(data)
  File "/home/richard/projects/Twisted/branches/udp-port-from-fd-5574-3/twisted/protocols/basic.py", line 445, in dataReceived
    if self.transport.disconnecting:
exceptions.AttributeError: '_ProcessEndpointTransport' object has no attribute 'disconnecting'

Change History (7)

comment:1 Changed 7 years ago by Richard Wall

This got things working for me, but #1933 may be the real solution.

=== modified file 'twisted/internet/endpoints.py'
--- twisted/internet/endpoints.py	2013-06-29 19:23:36 +0000
+++ twisted/internet/endpoints.py	2013-06-30 10:49:31 +0000
@@ -272,6 +272,7 @@
         methods on this object to write data to a child process.
     @type _process: L{interfaces.IProcessTransport} provider
     """
+    disconnecting = False
 
     def write(self, data):
         """

comment:2 Changed 7 years ago by Jean-Paul Calderone

Another solution would be for LineReceiver to stop having a hard dependency on a disconnecting attribute.

getattr(transport, 'disconnecting', False) is pretty gross, but it localizes the grossness to LineReceiver, which ultimately deserves to suffer for violating the transport interface.

comment:3 in reply to:  2 Changed 7 years ago by Richard Wall

Replying to exarkun:

Another solution would be for LineReceiver to stop having a hard dependency on a disconnecting attribute.

getattr(transport, 'disconnecting', False) is pretty gross, but it localizes the grossness to LineReceiver, which ultimately deserves to suffer for violating the transport interface.

Thanks for the suggestion. I've mentioned it in ticket:6357#comment:17

comment:4 in reply to:  2 Changed 7 years ago by Richard Wall

Replying to exarkun:

Another solution would be for LineReceiver to stop having a hard dependency on a disconnecting attribute.

The reason seems to be to prevent further calls to LineReceiver.lineReceived when transport.loseConnection has been triggered by a previous command in the same data.

See r7747.

Do we need to preserve that behaviour and if so how can it be done without checking that transport.disconnecting?

comment:5 Changed 4 years ago by Glyph

Owner: set to Glyph

comment:6 Changed 19 months ago by Wim Lewis

Cc: Wim Lewis added

comment:7 Changed 15 months ago by Glyph

Owner: Glyph deleted
Note: See TracTickets for help on using tickets.