summaryrefslogtreecommitdiffhomepage
path: root/control/controlhttp/controlhttpserver
diff options
context:
space:
mode:
authorM. J. Fromberger <fromberger@tailscale.com>2025-10-10 09:03:38 -0700
committerGitHub <noreply@github.com>2025-10-10 09:03:38 -0700
commit0a33aae823eb5604f7698ce1dad99605eaed97c2 (patch)
tree99abdaa49c18c5afcf18bfd134c23b93b13f9dbf /control/controlhttp/controlhttpserver
parentf157f3288d3f35ac348c237b514d7e7b092393ac (diff)
downloadtailscale-0a33aae823eb5604f7698ce1dad99605eaed97c2.tar.xz
tailscale-0a33aae823eb5604f7698ce1dad99605eaed97c2.zip
util/eventbus: run subscriber functions in a goroutine (#17510)
With a channel subscriber, the subscription processing always occurs on another goroutine. The SubscriberFunc (prior to this commit) runs its callbacks on the client's own goroutine. This changes the semantics, though: In addition to more directly pushing back on the publisher, a publisher and subscriber can deadlock in a SubscriberFunc but succeed on a Subscriber. They should behave equivalently regardless which interface they use. Arguably the caller should deal with this by creating its own goroutine if it needs to. However, that loses much of the benefit of the SubscriberFunc API, as it will need to manage the lifecycle of that goroutine. So, for practical ergonomics, let's make the SubscriberFunc do this management on the user's behalf. (We discussed doing this in #17432, but decided not to do it yet). We can optimize this approach further, if we need to, without changing the API. Updates #17487 Change-Id: I19ea9e8f246f7b406711f5a16518ef7ff21a1ac9 Signed-off-by: M. J. Fromberger <fromberger@tailscale.com>
Diffstat (limited to 'control/controlhttp/controlhttpserver')
0 files changed, 0 insertions, 0 deletions