Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove goprocess from Host #865

Merged
merged 3 commits into from
Apr 6, 2020
Merged

Remove goprocess from Host #865

merged 3 commits into from
Apr 6, 2020

Conversation

aarshkshah1992
Copy link
Contributor

Comment on lines 191 to 194
select {
case <-hostCtx.Done():
h.teardown()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
select {
case <-hostCtx.Done():
h.teardown()
}
<-hostCtx.Done()
h.teardown()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code has been removed.

@@ -812,7 +823,8 @@ func (h *BasicHost) Close() error {
// This:
// 1. May be called multiple times.
// 2. May _never_ be called if the host is stopped by the context.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment maybe out of date now?

Copy link
Contributor Author

@aarshkshah1992 aarshkshah1992 Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have removed this comment.

@@ -105,13 +106,15 @@ func NewIDService(ctx context.Context, h host.Host, opts ...Option) *IDService {
userAgent = cfg.userAgent
}

hostCtx, cancel := context.WithCancel(context.Background())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

being able to have the ID service run within a larger context continues to seem valuable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why. It's a separate service and exposes a Close function we can call to shut it down. This is similar to the DHT<-> Routing Table relationship and the same idea works fine for us there.

What are your concerns here ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a consumer is spinning up a bunch of separate services, it's nice to have them all wired up to a central context, and then cancel that context to shut things down, rather than explicitly calling close on each service.

Copy link
Contributor Author

@aarshkshah1992 aarshkshah1992 Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see where you are coming from but we've had problems in the past using contexts for cancellation across service boundaries. Please take a look at libp2p/go-libp2p-kbucket#50 (comment) & the linked discussions in that comment.

The most important benefit to me is being able to control the order in which the services, sub-components etc. are shut down.

currid: make(map[network.Conn]chan struct{}),
observedAddrs: NewObservedAddrSet(ctx),
observedAddrs: NewObservedAddrSet(hostCtx),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Stebalien

Should we also have a Close for the ObservedAddrSet that we can call in IDService.Close()

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some day, yes. But not today.

@aarshkshah1992
Copy link
Contributor Author

aarshkshah1992 commented Apr 2, 2020

@Stebalien Now that I think about it, if we had many go-routines in the Host, using goprocess would actually make more sense as we'd basically be mimicking it's behaviour. Does this comment make sense ?

@@ -343,7 +335,12 @@ func makeUpdatedAddrEvent(prev, current []ma.Multiaddr) *event.EvtLocalAddresses
return &evt
}

func (h *BasicHost) background(p goprocess.Process) {
func (h *BasicHost) background() {
h.refCount.Add(1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, this is racy. See the note on https://golang.org/pkg/sync/#WaitGroup.Add.

We have to call Add before we go async.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(otherwise background might not start running till after the user calls Close)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea how I missed this. Thanks for the catch.

func (h *BasicHost) background() {
h.refCount.Add(1)
defer func() {
h.refCount.Done()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: defer h.refCount.Done().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

func (ids *IDService) handleEvents() {
ids.refCount.Add(1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

func (ids *IDService) handleEvents() {
ids.refCount.Add(1)
sub := ids.subscription
defer func() {
_ = sub.Close()
// drain the channel.
for range sub.Out() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: we no longer need this (close will do it for us). We can simplify to:

defer ids.refCount.Done()
defer sub.Close()

Copy link
Contributor Author

@aarshkshah1992 aarshkshah1992 Apr 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a look at Sub.Close() in go-eventbus. You are right. This is done.

currid: make(map[network.Conn]chan struct{}),
observedAddrs: NewObservedAddrSet(ctx),
observedAddrs: NewObservedAddrSet(hostCtx),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some day, yes. But not today.

@Stebalien
Copy link
Member

@aarshkshah1992 LGTM. Could you make sure the test failures are that known issue then merge if so.

@aarshkshah1992
Copy link
Contributor Author

aarshkshah1992 commented Apr 6, 2020

@Stebalien The test that fails is TestLocalhostAddrFiltering . Merging now.

#854.

@aarshkshah1992 aarshkshah1992 merged commit 615f125 into master Apr 6, 2020
@aarshkshah1992 aarshkshah1992 deleted the feat/862 branch April 6, 2020 06:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants