-
Notifications
You must be signed in to change notification settings - Fork 892
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
os/StartProcess #4377
base: dev
Are you sure you want to change the base?
os/StartProcess #4377
Conversation
43fcf8f
to
8cce6c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick initial (incomplete) review
fffffce
to
0844543
Compare
ci fails with undefined EDIT: it looks like this is only happening on architectures that the Anyhow the smoke tests fail without any further information of what went wrong on linux, windows and mac. the smoke test cannot be removed, it is not clear though why it wasn't build in the first place
|
4189be1
to
a67e057
Compare
e369ae7
to
bf011fe
Compare
Signed-off-by: leongross <leon.gross@9elements.com>
… and macos Signed-off-by: leongross <leon.gross@9elements.com>
bf011fe
to
318e7b7
Compare
246b809
to
bbf1159
Compare
Signed-off-by: leongross <leon.gross@9elements.com>
bbf1159
to
ffa5a87
Compare
@deadprogram @dgryski @aykevl build and tests finally succeed, would appreciate another review. |
@aykevl @deadprogram @dgryski would someone mind reviewing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- There is some commented out code, that looks like testing code. IMHO it should either be used, or removed (it doesn't really add any value in documentation).
- You make a few changes to the syscall package, but why? All actual operating systems (Linux, macOS, Windows) use the default syscall package. If you need any changes to the syscall package, that probably indicates that it is called from somewhere (for example, baremetal) and you need to adjust build tags.
const ( | ||
SYS_FORK = 57 | ||
SYS_EXECVE = 59 | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These can be removed, because every actual operating system we have (Linux, MacOS, Windows) doesn't use the TinyGo syscall package.
(If removing these leads to compilation errors, you're probably using them from something that's not an operating system and probably need to adjust build tags at the call site).
src/os/osexec.go
Outdated
// ret := libc_fork() | ||
// ret, _, _ := syscall.Syscall(syscall.SYS_FORK, 0, 0, 0) | ||
ret, _, _ := syscall.Syscall(57, 0, 0, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't use magic numbers. Use syscall.SYS_FORK
instead, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the explicit syscall number and found out, that in the CI the definition for SYS_FORK cannot be found. Grepping through the source tree I found out, that there is no definition for this, only the local go installation provides this, e.g. via src/syscall/zsysnum_linux_amd64.go. What confused me is that the CI should have picked this up but did not. On my local machine, this works perfectly fine.
src/os/osexec.go
Outdated
|
||
// fail := libc_execve(&argv0[0], &argv1[0], &env1[0]) | ||
// fail, _, _ := syscall.Syscall(syscall.SYS_EXECVE, uintptr(unsafe.Pointer(&argv0[0])), uintptr(unsafe.Pointer(&argv1[0])), uintptr(unsafe.Pointer(&env1[0]))) | ||
fail, _, _ := syscall.Syscall(59, uintptr(unsafe.Pointer(&argv0[0])), uintptr(unsafe.Pointer(&argv1[0])), uintptr(unsafe.Pointer(&env1[0]))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't use magic numbers. It looks like you can use syscall.Exec
instead.
// TODO: parse the syscall return codes | ||
return errors.New("execve failed") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you implement this TODO?
(If you use syscall.Exec
you already have an error value to return!)
// * No setting of Process Attributes | ||
// * Ignoring Ctty | ||
// * No ForkLocking (might be introduced by #4273) | ||
// * No parent-child communication via pipes (TODO) | ||
// * No waiting for crashes child processes to prohibit zombie process accumulation / Wait status checking (TODO) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to check for these cases, and if users use any of these to return an error instead of continuing and not doing what the user expected?
For example, if Stdin
is set, it should either implement that feature or return an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like a reasonable thing to do. I will evaluate this and see how/if this is possible.
func (p *ProcessState) Exited() bool { | ||
return false // TODO | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's... a little ugly.
Is there any way we can track whether the process is still running?
remove old comments, replace explicit syscall numbers with named variants, undo tempfile seed generation, remove old // +build tags, improve StartProcess documentation. Signed-off-by: leongross <leon.gross@9elements.com>
This is a rework of #4323 (based on that branch) to move the Execve and Fork wrappers to the
os
package to circumvent the goroot overrides.