- I don't understand why you'd want more than one type of
Handler
perReader
, so why not addHandler
toReader
's constructor with an optional concurrencyint
onReader
? - A
HandlerFunc
function 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
Stop
must be followed by blocking on theExitChan
(which should be astruct{}
)? Why not simply makeStop
block until handlers have exited gracefully? Reader.Configure
is awkward, but makes sense if you want to provide validation forReader
fields. 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
ReaderConfig
type (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
Reader
initialization is non-obvious. I *t
This file contains 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 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.