go语言两路实时视频融合 Go语言实战流媒体视频网站

golang开发modbus-rtu通信

用到的gomodbus包是坛友slzm40编写和共享的，感谢他的无私分享，本帖只是抛砖引玉，将我自己学习的一些经历分享给大家；有关modbus包可以直接向slzm40请教或一起讨论；

成都创新互联-专业网站定制、快速模板网站建设、高性价比宜阳网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式宜阳网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖宜阳地区。费用合理售后完善，十年实体公司更值得信赖。

包地址"github.com/thinkgos/gomodbus"；

添加一对虚拟串口

打开modbus-slave从机软件，用来测试从机；

需要注意设置通信地址和读取寄存器的地址和数量；

查看可用串口，因为虚拟串口选择com1和com2，虚拟中我选择使用/dev/ttyS1

编译运行，会提示串口打开失败，这是因为linux对设备的权限做了限制

获取串口读写、运行等权限

我们已经能正确读取03寄存器的值；其他功能可以自行测试；

package main

import (

"fmt"

modbus "github.com/thinkgos/gomodbus"

"github.com/thinkgos/gomodbus/mb"

"time"

)

func main(){

//调用RTUClientProvider的构造函数,返回结构体指针

p := modbus.NewRTUClientProvider()

p.Address = "/dev/ttyS1"

p.BaudRate = 115200

p.DataBits = 8

p.Parity = "N"

p.StopBits = 1

p.Timeout = 100 * time.Millisecond

client := mb.NewClient(p)

client.LogMode(true)

err := client.Start()

if err != nil {

fmt.Println("start err,", err)

return

}

for {

value, err := client.ReadHoldingRegisters(1, 1, 3)

if err != nil {

fmt.Println("readHoldErr,", err)

} else {

fmt.Printf("%#v\n", value)

}

time.Sleep(time.Second * 3)

}

}

使用golang播放视频

使用go语言编写一个播放器，直接看效果

整体思路是使用ffmpeg解码，然后使用xui进行渲染，音频播放暂时还没调通，以下是源码

Golang 游戏leaf系列(六) Go模块

在 Golang 游戏leaf系列(一) 概述与示例 (下文简称系列一)中，提到过Go模块用于创建能够被 Leaf 管理的 goroutine。Go模块是对golang中go提供一些额外功能。Go提供回调功能，LinearContext提供顺序调用功能。善用 goroutine 能够充分利用多核资源，Leaf 提供的 Go 机制解决了原生 goroutine 存在的一些问题：

我们来看一个例子（可以在 LeafServer 的模块的 OnInit 方法中测试）：

这里的 Go 方法接收 2 个函数作为参数，第一个函数会被放置在一个新创建的 goroutine 中执行，在其执行完成之后，第二个函数会在当前 goroutine 中被执行。由此，我们可以看到变量 res 同一时刻总是只被一个 goroutine 访问，这就避免了同步机制的使用。Go 的设计使得 CPU 得到充分利用，避免操作阻塞当前 goroutine，同时又无需为共享资源同步而忧心。

这里主动调用了 d.Cb(-d.ChanCb) ，把这个回调取出来了。实际上，在skeleton.Run里会自己取这个通道

看一下源码：

New方法，会生成指定缓冲长度的ChanCb。然后调用Go方法就是先执行第一个func,然后把第二个放到Cb里。现在手动造一个例子：

这里解释一下，d.Go根据源码来看，实际也是调用了一个协程。然后上面两次d.Go并不能保证先后顺序。目前的输出结果是1+2那个先执行了，把3写入d.ChanCb，然后把3读出来，继续读时，d.ChanCb里没有东西，阻塞了。然后1+1那个协程启动了，最后又读到了2。

现在把time.Sleep(time.Second)的注释解开，会是啥结果呢

这里执行到time.Sleep睡着了，上面两个d.Go仍然是不确定顺序的，但是会各自的function先执行掉，然后陆续把cb写入d.ChanCb。看这次输出，1+2先写进去的。所以最后执行d.Cb时，就把3先读出来了。然后d.ChanCb的长度为1，说明还有一个，就是输出2了。

另外，就是close时会判断g.pendingGo

这个例子的意思很明显，NewLinearContext这种方式，即使先调用的慢了半秒，它还是会先执行完。

这里先是用了一个list，加入的时候用mutexLinearGo锁了，都加到最后。然后新开协程去处理，读的时候从最前面开始读，也要用mutexLinearGo锁。执行的时候，也要上锁mutexExecution，确保f()执行完并且写入g.ChanCb回调，这个mutexExecution锁才会解除。现在可以改造一个带回调的例子：

结果说明，确实是2先被写入了d.ChanCb。