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

adds the spawning process manager to run with scissors #158

Merged
merged 6 commits into from
Apr 5, 2024

Conversation

autodidaddict
Copy link
Contributor

No description provided.

@autodidaddict autodidaddict requested a review from a team as a code owner April 4, 2024 13:12
agent/agent.go Show resolved Hide resolved
@@ -34,26 +35,32 @@ type Agent struct {
cancelF context.CancelFunc
closing uint32
ctx context.Context
sigs chan os.Signal
Copy link
Contributor

Choose a reason for hiding this comment

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

Why don't we want to handle signals in the Agent? It would seemingly make even more sense to support signal handling in no-sandbox mode.

Copy link
Contributor Author

@autodidaddict autodidaddict Apr 4, 2024

Choose a reason for hiding this comment

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

We are handling signals. We weren't before. I'm just not using a channel to do it . In the code prior to this PR, we had the sigs channel but there was nothing sending to it... so basically we had a part of a select that would never fire.

Now instead of using the sigs channel, we're just using the same signal handler pattern we use in the node

Copy link
Contributor

Choose a reason for hiding this comment

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

The node uses a channel to ensure signals are handled serially. We can fix this to make it work like the node does later.

@@ -398,15 +408,42 @@ func (a *Agent) newExecutionProviderParams(req *agentapi.DeployRequest, tmpFile
return params, nil
}

func (a *Agent) setupSignalHandlers() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar concern regarding use of os.Exit here in setupSignalHandlers.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure we need Goexit here either, although this is interesting.

Copy link
Contributor

Choose a reason for hiding this comment

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

well, my point is, even if there are no defers before this Exit right YET, we shouldn't be using it at all.

agent/agent.go Show resolved Hide resolved
agent/agent.go Show resolved Hide resolved
jordan-rash
jordan-rash previously approved these changes Apr 4, 2024
Copy link
Contributor

@jordan-rash jordan-rash left a comment

Choose a reason for hiding this comment

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

This all looks good to me, only nits. That said, I still need to put all the changes from 155 apart to understand the full flow of everthing now, just havent had time yet

agent/agent.go Show resolved Hide resolved
@@ -398,15 +408,42 @@ func (a *Agent) newExecutionProviderParams(req *agentapi.DeployRequest, tmpFile
return params, nil
}

func (a *Agent) setupSignalHandlers() {
Copy link
Contributor

Choose a reason for hiding this comment

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

agent/agent.go Show resolved Hide resolved
examples/nodeconfigs/nosandbox.json Show resolved Hide resolved
internal/node/spawn_procman.go Show resolved Hide resolved
@autodidaddict
Copy link
Contributor Author

autodidaddict commented Apr 5, 2024

@jordan-rash the runtime Goexit only affects the current goroutine... it doesn't actually terminate the application. This means we could add a go statement somewhere else in the code and this would stop exiting

Just from a quick glance I can see at least 4 other go routines that would be running at the time Goexit was called.

From the docs:

Calling Goexit from the main goroutine terminates that goroutine without func main returning. Since func main has not returned, the program continues execution of other goroutines. If all other goroutines exit, the program crashes.

This seems like a particularly dangerous way to exit an application. It explicitly doesn't shut the app down or even finish the main func

Copy link
Contributor

@kthomas kthomas left a comment

Choose a reason for hiding this comment

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

I will update the spec suite in a new PR.

@autodidaddict autodidaddict merged commit 6550e09 into main Apr 5, 2024
3 checks passed
@autodidaddict autodidaddict deleted the feat/nosandbox branch April 5, 2024 13:47
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