Create a master Context in the per-session ReqeustServer.Serve method
that is then used as the parent for all Context's created in that
server. Its cancelFunc is then always called when Serve exits. This is
in line which out the http.serve code works.
Each Request gets a child WithCancel context created in the
requestFromPacket call. This Context is still closed on request.close().
In #192 we normalized all Request use to have pointer receivers. This
simplified reasoning and allowed for a simpler Request struct. This
change completes that work by eliminating the need for the
state/stackLock pointers and also removes the need for a new Request
each packet, reducing the pressure on the GC.
The main bit is that the RequestServer.openRequests[] map now stores Request
pointers and it only creates new Requests (replacing the mapped entry) when the
Method changes. It never updates/modifies an existing Request and the packet to
Method mapping is now all in place place (requestMethod).
Fix#207
The primary issue of the resolved ticket was path cleaning code returned
the path of '/.' instead of '/'.
We also reviewed and clarified the use of filepath/path and how OS
specific paths are handled in the server code. All paths are converted
to POSIX paths as they come into the server. They are then POSIX paths
for all internal operations.
Splitted cleanPath into cleanPacketPath and cleanPath for better handling of slashes in file paths
Added test for cleanPath func
Removed code duplication => filepath.ToSlash(filepath.Clean(...)) => cleanPath(...)
Fixed tests for runLs to match year or time
Renamed constants to fit hound rules
I didn't like how the initial fix for #184 required the handler author
to track the token/offset for the filelist. I came up with a way to do
it that mimic'd the FileReader handler interface using a method
something like ReaderAt except for file lists.
changed MaxFileinfoList to a var for testing and tweaking
Renaming FileInfoer interface to FileLister.
FileInfoer -> FileLister
Fileinfo -> Filelist
The request server needs to support batching of file list requests. To
address this the methods LsSave(string) and LsNext()string are added to
the Request object. They should work to store a token to keep your place.
The Handler should now return an EOF when the end of the directory list is
reached. If it doesn't but returns an empty list, the wrapper will send the EOF
for you.
The old behaviour of just returning 1 batch and sending the EOF is preserved if
you don't set the token (you don't use LsSave). It will return the 1 list and
EOF on the next underlying readdir call. This is to preserve backwards
compatibility and it not the recommended way to handle file lists.
Added a test that breaks w/ old code which has typos but is fixed with
typos fixed. Also added switch-default error message that would have
helped diagnose this (should have been there already).
Encapsulate stateful data into sub-structures with pointer references
from the Request structure. This allows me to pass by value in most
cases to keep non-stateful (write once) data data race free and tightly
controlling access to stateful data to ease locking.
Was using a filename as a placeholder for something that would allow for
stateless servers but decided the amount of work wasn't worth it at this
point. So I went back to the auto-inc number as it doesn't have the size
issues (max handle length is 256).
John Eikenberry
Allan Feid
sandreas
Artyom Pervukhin