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

net: enable native golang linux networking #4498

Open
wants to merge 13 commits into
base: dev
Choose a base branch
from

Conversation

leongross
Copy link
Contributor

@leongross leongross commented Oct 4, 2024

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.

@leongross leongross force-pushed the net-linux-nonlinux branch 7 times, most recently from bbd514e to fdc75d6 Compare October 8, 2024 09:35
@leongross leongross marked this pull request as ready for review October 8, 2024 09:47
Copy link
Member

@aykevl aykevl left a 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.

loader/goroot.go Outdated Show resolved Hide resolved
.gitmodules Outdated Show resolved Hide resolved
Comment on lines 7 to 9
panic("todo: semacquire")
// TODO the "net" pkg calls this, so panic() isn't an option. Right
// now, just ignore the call.
// panic("todo: semacquire")
Copy link
Member

@aykevl aykevl Oct 10, 2024

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).

Copy link
Contributor Author

@leongross leongross Oct 28, 2024

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.

Copy link
Member

@aykevl aykevl Nov 4, 2024

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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?

src/os/exec.go Outdated Show resolved Hide resolved
@leongross
Copy link
Contributor Author

@aykevl I will add some basic tests. Since I already did some testing (I hope) it should be fairly easy to integrate this here.

@leongross leongross mentioned this pull request Oct 11, 2024
@leongross leongross force-pushed the net-linux-nonlinux branch 4 times, most recently from 4ec411d to e1f18b2 Compare October 28, 2024 09:57
@leongross leongross requested a review from aykevl November 4, 2024 10:06
@leongross leongross force-pushed the net-linux-nonlinux branch 3 times, most recently from 81fd6ff to 52be3d8 Compare November 4, 2024 16:32
src/syscall/forklock.go Outdated Show resolved Hide resolved
Comment on lines 21 to 28
// 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
Copy link
Member

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.

Copy link
Contributor Author

@leongross leongross Nov 11, 2024

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

Suggested change
// 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

I think @scottfeldman did this to circumvent some import cycles, not sure if they still hold, I will investigate this.

Comment on lines +15 to +18
// "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."
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comment on lines +36 to +43
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
}
Copy link
Member

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?

Comment on lines +47 to +49
if cansemacquire(sema) {
return
}
Copy link
Member

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).

.gitmodules Outdated Show resolved Hide resolved
GNUmakefile Outdated Show resolved Hide resolved
Comment on lines 18 to 19
println("poll_runtime_pollReset not implemented", pd, mode)
return 1
Copy link
Member

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.

Copy link
Contributor Author

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")
Copy link
Member

@aykevl aykevl Nov 8, 2024

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?)

src/os/exec.go Outdated Show resolved Hide resolved
@leongross leongross force-pushed the net-linux-nonlinux branch 3 times, most recently from 3ad4d5d to 1831075 Compare November 8, 2024 16:14
Signed-off-by: leongross <[email protected]>
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 <[email protected]>
Signed-off-by: leongross <[email protected]>
@leongross leongross force-pushed the net-linux-nonlinux branch 2 times, most recently from b3412a9 to 63e2443 Compare November 8, 2024 17:08
@leongross leongross force-pushed the net-linux-nonlinux branch 2 times, most recently from b672958 to 72cea16 Compare November 11, 2024 11:40
Signed-off-by: leongross <[email protected]>
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