Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | run isort | Amber Brown | 2018-07-09 | 1 | -4/+4 |
| | |||||
* | Pass around the reactor explicitly (#3385) | Amber Brown | 2018-06-22 | 1 | -5/+6 |
| | |||||
* | Remove spurious unittest.DEBUG | Richard van der Hoff | 2018-05-02 | 1 | -1/+0 |
| | |||||
* | Fix a class of logcontext leaks | Richard van der Hoff | 2018-05-02 | 1 | -11/+56 |
| | | | | | | | | | | | | | | | | So, it turns out that if you have a first `Deferred` `D1`, you can add a callback which returns another `Deferred` `D2`, and `D2` must then complete before any further callbacks on `D1` will execute (and later callbacks on `D1` get the *result* of `D2` rather than `D2` itself). So, `D1` might have `called=True` (as in, it has started running its callbacks), but any new callbacks added to `D1` won't get run until `D2` completes - so if you `yield D1` in an `inlineCallbacks` function, your `yield` will 'block'. In conclusion: some of our assumptions in `logcontext` were invalid. We need to make sure that we don't optimise out the logcontext juggling when this situation happens. Fortunately, it is easy to detect by checking `D1.paused`. | ||||
* | Optimise LoggingContext creation and copying | Richard van der Hoff | 2018-01-16 | 1 | -8/+8 |
| | | | | | | | | It turns out that the only thing we use the __dict__ of LoggingContext for is `request`, and given we create lots of LoggingContexts and then copy them every time we do a db transaction or log line, using the __dict__ seems a bit redundant. Let's try to optimise things by making the request attribute explicit. | ||||
* | Fix name of test_logcontext | Richard van der Hoff | 2017-10-17 | 1 | -0/+134 |
The file under test is logcontext.py, not log_context.py |