exit on stdin close #1212
No reviewers
Labels
No Label
Benchmarking and Performance
HTTP Storage Protocol
Nevow Removal
Python 3 Porting
not-for-merge
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tahoe-lafs/tahoe-lafs#1212
Loading…
Reference in New Issue
No description provided.
Delete Branch "3921.exit-on-stdin-close"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes🎫3921
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3921#ticket
Anyone know what's up on the Windows builders? The coverage job seems to succeed (and maybe there's some sort of error trying to print the report?)
The test run includes this output:
That seems remarkably unfortunate...
Oh, I didn't see the "out of space" ... looking at all of them, 3.7 and 3.8 have "out of space" and 3.9 and 3.10 fail during writing the report (but don't have an "out of space" exception ... although perhaps its the same reason?)
I guess on the "good news" front, all the tests themselves appear to pass :/
Thanks. Some comments inline. Please address and merge.
@ -200,4 +209,3 @@
return d
from twisted.internet import reactor
reactor.callWhenRunning(start)
Let's catch and ignore ReactorNotRunning but log other stuff? It's always sad when this kind of handling hides a SyntaxError or a NameError or some other simple programming mistake.
only for Windows testing purposes?
It returns the
StandardIO
so I'd call thistransport
probably.This was pretty confusing until I recognized that
proto
is aStandardIO
andwriteConnectionLost
/readConnectionLost
here don't refer toIHalfCloseableProtocol
but just happen to be the names of the WindowsStandardIO
implementation details for stdin/stdout closed notification. :/Too bad Twisted doesn't provide a usable
StandardIO
test double, I guess? Maybe we can ask for one.Since lines 649-658 are duplicated in the next test, I'd at least pull them out into a shared helper function.
yes .. because we need to call
.writeConnectionLost()
by hand there Because Reasons.Hrrmmm ... two "dead reference errors" and two "disk full" on windows :/
Coverage decreased (-0.003%) to 94.692% when pulling
3d831f653b
on meejah:3921.exit-on-stdin-close into7cc023a590
on tahoe-lafs:master.