andeya / goutil Goto Github PK

如果go版本号是1.18beta，versioning.Parse(goVersion)解析不出后面的beta，会返回一个error，这会触发后面的panic

go version
go version go1.18beta2 windows/amd64

https://github.com/henrylee2cn/goutil/blob/5b5425bff75ce88e91a6122e91fb7f0d751b8d16/tpack/tpack.go#L20-L27

package ***
        imports ***
        imports ***
        imports github.com/henrylee2cn/goutil
        ../../../../../pkg/mod/github.com/henrylee2cn/[email protected]/encrypt.go:17:2: use of internal package github.com/andeya/goutil/internal/ameda not allowed

Boom!

@henrylee2cn
1.这里workshop相当于在100万个协程中分别执行，和不使用workshop有啥区别？ worker并不是在一个协程执行的啊？
https://github.com/henrylee2cn/goutil/blob/5b5425bff75ce88e91a6122e91fb7f0d751b8d16/pool/workshop_test.go#L73-L83

2.workshop和直接使用协程对比
=== RUN TestGoChan
--- PASS: TestGoChan (0.30s)
workshop_test.go:35: pool_size:50, requests:100000, one_logic_cost:10ms, total_cost:295ms, QPS:338983
=== RUN TestChanPool
--- PASS: TestChanPool (20.04s)
workshop_test.go:35: pool_size:50, requests:100000, one_logic_cost:10ms, total_cost:20.043s, QPS:4989
=== RUN TestWorkshop
--- PASS: TestWorkshop (0.39s)
workshop_test.go:100: workshop stats: {Worker:50 Idle:50 Created:50 Doing:0 Done:100000 MaxLoad:0 MinLoad:0}
workshop_test.go:35: pool_size:50, requests:100000, one_logic_cost:10ms, total_cost:394ms, QPS:253807
goos: windows
goarch: amd64
pkg: workshop
其中第一个是仅使用100万go 协程，代码如下：
`
wg := new(sync.WaitGroup)

wg.Add(requests)
startNano := time.Now().UnixNano()
for i := 0; i < requests; i++ {
	go func() {
		defer wg.Done()
		worker := 	&testWorker{}
		worker.Do()
	}()
}
wg.Wait()
reportStat(t, startNano)`

https://github.com/henrylee2cn/goutil/blob/master/calendar/festival.go
第40行，应该是
defer file.Close()

我使用的是 go mod 管理包

我使用 go mod tidy 后只会下载

github.com/henrylee2cn/goutil v0.0.0-20190226083422-6a93115ffd79 // indirect

会报错

build command-line-arguments: cannot load github.com/henrylee2cn/goutil/tpack: cannot find module providing package github.com/henrylee2cn/goutil/tpack

当semVer="1.11"时Parse方法会return nil errors.New("invalid semantic version 2: " + semVer )导致tpack.go init的时候直接panic

I know its kind of obvious for an straightforward implementation but it should still be mentioned along with the name of service.

你好， 最近看了一下你的视频和源码。
在 hire worker的时候进行了worker的健康状态检查。
假设有这样一个场景：
worker a 目前正在有n个任务子在执行（n个任务在hire worker的时候都没有发生错误），
此时worker a 也是负载最小的一个，新来了一个任务b， 任务b会被分配给woker a 执行， 但是在分配的时候检测到worker a不正常了， 此时采取的策略是关闭 worker a。 但是worker a此时有n个任务被绑定执行， 那岂不是这n个任务全部失败了？