- I don't understand why you'd want more than one type of
HandlerperReader, so why not addHandlertoReader's constructor with an optional concurrencyintonReader? - A
HandlerFuncfunction type would be a nice alternative interface for stateless handlers or closures. - Graceful shutdown is confusing and awkward. A (non-blocking) 30 second sleep in
Stopmust be followed by blocking on theExitChan(which should be astruct{})? Why not simply makeStopblock until handlers have exited gracefully? Reader.Configureis awkward, but makes sense if you want to provide validation forReaderfields. However, it seems strange to make the fields public and provide a setter with no indication which is the proper mechanism to use.- Perhaps a separate
ReaderConfigtype (liketls.Config) which could be built as a struct literal and passed toReader.Configure(or a constructor?) would allow for validation and public fields. - Proper
Readerinitialization is non-obvious. I *t
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #!/usr/bin/env python | |
| import sys | |
| CHUNK = 100 | |
| if len(sys.argv) > 1: | |
| CHUNK = int(sys.argv[1]) | |
| vals = [] | |
| i = 1 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #!/usr/bin/env python | |
| import sys | |
| import math | |
| CHUNK = 100 | |
| if len(sys.argv) > 1: | |
| CHUNK = int(sys.argv[1]) | |
| s = 0 |
aka Service Lifecycle Contexts
Request-scoped contexts are unambigiously good. Other than a brief mention of main() they're the only use case covered by the official context announcement and documentation. Every single feature of contexts makes sense in a request/response scenario:
- Cancelation provides a unified API for canceling work whose result is no longer needed
- Deadlines and timeouts provide a unified API for preventing requests from blocking indefinitely.