- 01 Aug, 2019 10 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
because the push phase of unpending happens outside the tree lock, we need to ensure only one thread is ever entering unpending this is in preparation for future changes, right now, unpending is only ever called from the topreq thread
-
Nils Goroll authored
This is the first step towards bringing back safe front pushes: For a thread in vdp_push bytes, it is safe to push upwards if it owns all ST_OPEN T_NEXUS nodes upwards or if they are ST_CLOSED or ST_DELIVERED. more to come in later commits
-
- 31 Jul, 2019 30 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
it is only needed in the esi parser and for some sanity checks
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Geoff Simmons authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Geoff Simmons authored
-
Nils Goroll authored
much of the rest of the unpend design and state management assumes that nexuses got nodes below. By all means we do not want to start removing nodes from the tree, because that would introduce even more sync or races with unpending, so the logical solution is to turn the node into a zero T_DATA node.
-
Nils Goroll authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Geoff Simmons authored
-
Nils Goroll authored
ref: 5a03b1ef we do need to differentiate the cases here, depending on which one, we need to fini the task before or after some other action.
-
Nils Goroll authored
-
Nils Goroll authored
once the subreq is picked up by delivery, it could no longer be true
-
Nils Goroll authored
sometimes accounting is missing 8 bytes - we would expect: ReqAcct "^29 0 29 192 104 296$ because, when this happens, the subreq accounting and the response are correct, I assume this to be an issue in varnish-cache
-