英文:
How to place http.Serve in its own goroutine if it blocks?
问题
http.Serve在被调用时要么立即返回错误，要么在成功执行时阻塞。
我该如何使其在阻塞时在自己的goroutine中执行？我目前有以下代码：
func serveOrErr(l net.Listener, handler http.Handler) error {
starting := make(chan struct{})
serveErr := make(chan error)
go func() {
starting <- struct{}{}
if err := http.Serve(l, handler); err != nil {
serveErr <- err
}
}()
<-starting
select {
case err := <-serveErr:
return err
default:
return nil
}
}
这看起来是一个不错的开始，在我的测试机器上工作正常，但我认为不能保证 serveErr <- err 在 case err := <-serveErr 之前被调用，因此可能导致不一致的结果，因为存在数据竞争，如果 http.Serve 产生错误的话。
英文:
http.Serve either returns an error as soon as it is called or blocks if successfully executing.
How can I make it so that if it blocks it does so in its own goroutine? I currently have the following code:
func serveOrErr(l net.Listener, handler http.Handler) error {
starting := make(chan struct{})
serveErr := make(chan error)
go func() {
starting <- struct{}{}
if err := http.Serve(l, handler); err != nil {
serveErr <- err
}
}()
<-starting
select {
case err := <-serveErr:
return err
default:
return nil
}
}
This seemed like a good start and works on my test machine but I believe that there are no guarantees that serveErr <- err would be called before case err := <-serveErr therefore leading to inconsistent results due to a data race if http.Serve were to produce an error.
答案1
得分: 4
http.Serve函数在被调用时要么立即返回错误，要么在成功执行时阻塞。
这个假设是不正确的，我相信这种情况很少发生。http.Serve 在循环中调用了 net.Listener.Accept，错误可能随时发生（例如，套接字关闭，打开的文件描述符过多等）。通常用于运行 HTTP 服务器的 http.ListenAndServe 函数在绑定监听套接字时经常会早期失败（没有权限，地址已被占用）。
在我看来，除非你的 net.Listener.Accept 在第一次调用时出现了某种原因导致的失败，否则你所尝试的做法是错误的。如果你想确保服务器正常工作，你可以尝试连接它（也许实际传输一些数据），但一旦成功绑定了套接字，我认为这并不是真正必要的。
英文:
> http.Serve either returns an error as soon as it is called or blocks if successfully executing
This assumption is not correct. And I believe it rarely occurs. http.Serve calls net.Listener.Accept in the loop – an error can occur any time (socket closed, too many open file descriptors etc.). It's http.ListenAndServe, usually being used for running http servers, which often fails early while binding listening socket (no permissions, address already in use).
In my opinion what you're trying to do is wrong, unless really your net.Listener.Accept is failing on the first call for some reason. Is it? If you want to be 100% sure your server is working, you could try to connect to it (and maybe actually transmit something), but once you successfully bound the socket I don't see it really necessary.
答案2
得分: 1
你可以在select语句中使用超时，例如：
timeout := time.After(5 * time.Millisecond) // TODO: 调整数值
select {
case err := <-serveErr:
return err
case _ := <-timeout:
return nil
}
这样，你的select语句将会阻塞，直到serveErr有值或者指定的timeout时间过去。请注意，因此你的函数的执行将会阻塞调用它的goroutine，最多持续指定的超时时间。
Rob Pike关于Go并发模式的精彩演讲可能会有所帮助。
英文:
You could use a timeout on your select statement, e.g.
timeout := time.After(5 * time.Millisecond) // TODO: ajust the value
select {
case err := <-serveErr:
return err
case _ := <- timeout:
return nil
}
This way your select will block until serveErr has a value or the specified timeout has elapsed. Note that the execution of your function will therefore block the calling goroutine for up to the duration of the specified timeout.
Rob Pike's excellent talk on go concurrency patterns might be helpful.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论