-
Notifications
You must be signed in to change notification settings - Fork 911
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
net: enable native golang linux networking #4498
base: dev
Are you sure you want to change the base?
Conversation
bbd514e
to
fdc75d6
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.
How did you test this?
To accept this into TinyGo, I'd like to see at least some tests. For example, you can create a new test like testdata/net.go (and add it to main_test.go for Linux only). It doesn't have to be exhaustive, but for example you can start a socket server (net.Listen
) in a goroutine and try to connect to it from the same program.
src/runtime/sync.go
Outdated
panic("todo: semacquire") | ||
// TODO the "net" pkg calls this, so panic() isn't an option. Right | ||
// now, just ignore the call. | ||
// panic("todo: semacquire") |
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 do this. There is a very good reason this panics: it is a reminder this should be implemented when it is used.
So either restore the panic, or actually implement semacquire
and semrelease
.
(It's probably easier to implement the internal/poll package instead in a way that works with TinyGo - but even that might be rather complex).
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.
Maybe I am missing something here, but since tinygo at the moment only supports a single os thread, it would be sufficient to implement this using a simple mutex, right? Making this code panic will eventually reduce usability for this drastically.
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.
No. All this API provides is a uint32
to store state. That's not enough to store a queue of waiting goroutines and the counter as would be needed for proper semaphore support. I don't think this can even be implemented in the current scheduler - at leat, not without some expensive data structures on the side. It is relatively easy to implement with a futex though, as I have in my threading PR: #4559
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 see that PR #4559 is still a wip. Maybe we should consider pulling out the futex functionality first to make some progress here?
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.
@aykevl does this sound like a good approach to you?
@aykevl I will add some basic tests. Since I already did some testing (I hope) it should be fairly easy to integrate this here. |
4ec411d
to
e1f18b2
Compare
81fd6ff
to
52be3d8
Compare
src/syscall/forklock.go
Outdated
// So for now, make our own stubbed-out ForkLock that doesn't use sync.. | ||
|
||
type forklock struct{} | ||
|
||
func (f forklock) RLock() {} | ||
func (f forklock) RUnlock() {} | ||
|
||
var ForkLock forklock |
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. You're basically removing all safety here and breaking the API contract.
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.
This again was stub code to get the poc working. Since your PR introduces threat safe mutexes we could replace it with
// So for now, make our own stubbed-out ForkLock that doesn't use sync.. | |
type forklock struct{} | |
func (f forklock) RLock() {} | |
func (f forklock) RUnlock() {} | |
var ForkLock forklock | |
var ForkLock sync.RWMutex |
// "That is, don't think of these as semaphores. | ||
// Think of them as a way to implement sleep and wakeup | ||
// such that every sleep is paired with a single wakeup, | ||
// even if, due to races, the wakeup happens before the sleep." |
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.
Ah, that's useful to know. So they're not really semaphores but something like it.
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.
type semTable [semTabSize]struct { | ||
root semaRoot | ||
pad [64 - unsafe.Sizeof(semaRoot{})]byte // only 64 x86_64, make this variable | ||
} | ||
|
||
func (t *semTable) rootFor(addr *uint32) *semaRoot { | ||
return &t[(uintptr(unsafe.Pointer(addr))>>3)%semTabSize].root | ||
} |
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 explain what this is doing, and what it's for?
if cansemacquire(sema) { | ||
return | ||
} |
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.
This doesn't look like a complete implementation?
You need to wait for the other goroutine to do a semrelease
. (This would be easy with multithreading and real OS futexes, but they don't exist yet).
Either you can busy loop with Gosched()
(terrible idea) or put the waiting goroutine in a hashmap to be awoken by semrelease
(slightly less terrible idea).
src/runtime/netpoll_generic.go
Outdated
println("poll_runtime_pollReset not implemented", pd, mode) | ||
return 1 |
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.
This is also a bad idea. Either implement it, or exit with 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.
Returning 1 here indicates an error for this context. I added the proper definitions that should make it more clear.
panic("todo: runtime_pollServerInit") | ||
// fmt.Printf("poll_runtime_pollServerInit not implemented, skipping panic\n") |
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.
If you put in debugging code, please remove it before sending in a PR. It makes the diff bigger and more work to review.
Generally, take a look at the PR diff and see if there's any part of it that is not necessary and can be removed (such as the changes to .gitmodules
and the signal changes that are still part of this PR).
(Also, how do you know that you can just remove this panic?)
72cea16
to
182dd87
Compare
Signed-off-by: leongross <leon.gross@9elements.com>
Signed-off-by: leongross <leon.gross@9elements.com>
if this does not work, do the folliwing steps: 1. remove net submodule 2. remove symlink in local ~/.cache/tinygo/goroot-<hash>/net 3. manual symlink yo local golang /usr/local/bin/src/net Signed-off-by: leongross <leon.gross@9elements.com>
Signed-off-by: leongross <leon.gross@9elements.com>
Signed-off-by: leongross <leon.gross@9elements.com>
Signed-off-by: leongross <leon.gross@9elements.com>
Signed-off-by: leongross <leon.gross@9elements.com>
e2e6576
to
1986937
Compare
Signed-off-by: leongross <leon.gross@9elements.com>
1986937
to
5f0f0aa
Compare
_, err := exec.LookPath(emulatorCommand) | ||
if err != nil { | ||
if _, err := exec.LookPath(emulatorCommand); err != nil { |
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 make unrelated changes in the PR. While this is probably a good idea, it would be better to make a separate cleanup PR instead of putting everything in one huge PR.
This is a rework of the plain linux network POC #4460. This PR adds adaptive switching of network packages depending on the
GOOS
.The CI fails due to unadjusted build tags for MacOs and WASm.
Successfully tested on
linux/amd64
.