-
Notifications
You must be signed in to change notification settings - Fork 900
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 <[email protected]>
… and macos Signed-off-by: leongross <[email protected]>
bf011fe
to
318e7b7
Compare
246b809
to
bbf1159
Compare
Signed-off-by: leongross <[email protected]>
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.
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.
// * 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?
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.
For now, I stubbed it out the same way all the other methods over ProcessState
(which is an empty struct) are implemented. Making this functional would mean a quite large rework of the tinygo process representation, which atm is just a pid. I think it is a good idea to rework this, but not as part of this PR.
remove old comments, replace explicit syscall numbers with named variants, undo tempfile seed generation, remove old // +build tags, improve StartProcess documentation, remove custom syscall number definitions. Signed-off-by: leongross <[email protected]>
17d1525
to
79ecb29
Compare
@leongross still are some CI failures from this PR is would appear. |
I figured out the error here: there is no fork syscall on arm64 1. The original golang implementation abstracts this better and does not do raw syscalls as my implementation does. So for now, arm64 has to be excluded as a possible target architecture for this. |
aarch64 has no support for the fork ssycall. for now exclude it. Signed-off-by: leongross <[email protected]>
978709f
to
5dc63dc
Compare
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.