Accessing river.Workers from the river.Client (or maybe all river.Config)

[mitar]

So I initialize river.Client in a different place where I then register workers. It looks like currently I have to both create river.Workers, pass it to river.Client as river.Config, and then I have now pass both client and workers around to be able to both submit jobs and register workers. It would be nice if I could obtain workers from client instance. Or maybe even simply, to be able to access passed config stored inside river.Client. Maybe river.Client could get Config method returning river.Config?

[brandur]

I admit that I have run into places where it would've been useful to get ahold of the Config struct after client initialization, though it hasn't been a huge problem for me.

I think the main downside is that by exposing it, it might imply that it's possible to modify configuration after client start and have an effect. For some fields, it may actually be possible modify client configuration after start if the client's internal loops are reading off the config struct. This may also introduce some potential parallel unsafety if you have a client goroutine and an external goroutine accessing a config property at the same time. This is currently impossible because the client dups the passed in configuration object on start.

My gut instinct is that it'd probably be better to continue making people keep a reference to Config if they still want access to it, but I suppose I don't feel super strongly about it.

@bgentry Any thoughts?

[mitar]

I think in Go we are pretty used to not be modifying structs after use. I mean, one could try to modify http.Server struct after starting the HTTP server, but it would not be a smart move. And it is not even documented that it is not allowed.

I thin it would be enough just to document with a line, that modifications should not be done after start. In any case you will get data races.