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

Implement proc_raise #290

Closed
wants to merge 1 commit into from
Closed

Implement proc_raise #290

wants to merge 1 commit into from

Conversation

nullpo-head
Copy link
Contributor

Signed-off-by: Takaya Saeki takaya@tetrate.io

Signed-off-by: Takaya Saeki <takaya@tetrate.io>
@codefromthecrypt
Copy link
Contributor

thanks for the straw man. I think this is best decoupled from OS handling especially what is supported by what OS is out of scope for us especially in documenting the WASI part.

Here's the suggestion:

add this type to the public wasi package, documenting that it is for proc_raise

type SignalHandler func(sig uint32) wasi.Errno

Add a default impl which only handles the exit signal and calls exit 1

ex.

var defaultSignalHandler SignalHandler = func(sig uint32) wasi.Errno {
   if exit or kill ... panic(wasi.ExitCode(exitCode))
}

add an option to override SignalHandler

Implement a built-in one for the current process, which I guess is only viable for Wasm-only processes. implement and cast the signals as syscall.Signal() and map go error to an errno
ex.


type currentPidSignalHandler { process}
func CurrentPidSignalHandler() (SignalHandler, err) {
// lookup process or fail
   return &currentPidSignalHandler{process}
}

// implementation is mainly just calling process.Signal

This allows unit tests to be easy as you can override SignalHandler. Also you can stick with cursory tests for the CurrentPidSignalHandler() for example, only testing when the OS isn't windows for now. What Go supports is out of scope and if someone wants to kill a process on windows we can ask and re-use code from func-e at that point.

@codefromthecrypt
Copy link
Contributor

ps only add the SignalHandler type to the public wasi package.. the others leave internal. Of course similar to other things holes will need to be punched in wazero.WASIConfig

@codefromthecrypt
Copy link
Contributor

Looks like we need to implement #293 and handle at least sigabrt (for AssemblyScript) and whatever grain ends up calling. Process exit is deprioritized as current use cases don't affect the host process. In fact, we can probably drop that entirely as no-one asked for it and stick with module or maybe also store scope. This focuses the pull review on code needed and leaves the gnarly os.Signal stuff out of it

@nullpo-head
Copy link
Contributor Author

As discussed in #271 (comment), proc_raise is no longer necessary. I close this draft PR.

@nullpo-head nullpo-head closed this Mar 9, 2022
@mathetake mathetake deleted the wasi_implement_proc_raise branch March 23, 2022 04:32
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.

2 participants