文章摘要
文章介绍了一个名为swift-erlang-actor-system的新项目,该项目使Swift程序能够加入分布式Erlang集群。通过封装Erlang的C节点功能,Swift的分布式参与者系统可以与Erlang节点进行通信。文章还提供了一个简单的聊天程序示例,并指导用户如何开始使用该系统。
文章总结
标题:介绍swift-erlang-actor-system - 社区展示 - Swift论坛
主要内容:
我们很高兴向大家介绍一个为Swift分布式Actor构建的新系统:swift-erlang-actor-system。该系统允许Swift程序加入分布式Erlang集群。
功能概述:
分布式Erlang连接:Erlang(及其虚拟机上的其他语言)可以通过分布式Erlang将多个运行时系统连接在一起。每个运行时系统被称为一个“节点”。Erlang还支持“C节点”,允许非Erlang运行时系统的程序与Erlang节点和其他C节点通信。
Swift与Erlang的互操作性:我们将C节点功能封装成一个Actor系统,可以与Swift的分布式Actor一起使用。通过该系统,Swift程序可以与Erlang节点进行通信。
使用示例:
安装Elixir:按照Elixir安装指南进行安装。例如,在macOS上可以使用Homebrew安装:
brew install elixir启动
epmd:启动“Erlang端口映射守护进程”,这是Erlang节点通过名称而不是IP和端口相互发现的方式:epmd启动Elixir节点并获取cookie和主机名:
iex --sname elixir_nodeiex(elixir_node@YOUR_HOSTNAME)> Node.get_cookie() :YOUR_COOKIE创建Swift包并设置节点和分布式Actor: ```swift import ErlangActorSystem import Distributed
@StableNames distributed actor Counter { typealias ActorSystem = ErlangActorSystem
private(set) var count: Int = 0 @StableName("increment") distributed func increment() { count += 1 print(count) } @StableName("decrement") distributed func decrement() { count -= 1 print(count) }}
let actorSystem = try await ErlangActorSystem(name: "swiftnode", cookie: "LJTPNYYQIOIRKYDCWCQH") try await actorSystem.connect(to: "elixirnode@DCKYRD-NMXCKatri") let counter = Counter(actorSystem: actorSystem) actorSystem.register(counter, name: "counter")
while true {} ```
从Elixir向Swift节点发送消息:
iex(elixir_node@YOUR_HOSTNAME)> GenServer.cast({:counter, :"swift_node@YOUR_HOSTNAME"}, :increment) iex(elixir_node@YOUR_HOSTNAME)> GenServer.cast({:counter, :"swift_node@YOUR_HOSTNAME"}, :decrement)
设计细节:
erl_interface库:swift-erlang-actor-system使用Erlang/OTP的erl_interfaceC库进行网络和序列化操作。消息序列化:分布式Erlang使用外部术语格式来序列化Erlang VM中的任何值。
erl_interface提供了编码/解码术语的函数。稳定名称:为了在跨语言Actor系统中识别远程调用,我们引入了
@StableNames宏,允许为Actor的方法提供自定义的唯一名称。
未来展望:
我们期待听到大家对这个Actor系统以及Swift分布式Actor的反馈。希望未来能在Swift中集成类似的功能。
相关项目:
elixir_pack:用于在iOS和其他Apple平台上打包和运行Elixir应用程序的包。使用WebSockets:支持自定义传输层,例如使用WebSockets代替原始TCP套接字。
总结:
swift-erlang-actor-system为Swift和Erlang之间的互操作性提供了一个强大的解决方案,使得跨语言分布式系统的开发更加便捷。
评论总结
关于Swift的自动引用计数(ARC)性能问题:
- 主要观点:Swift的ARC依赖于原子操作,这些操作可能带来性能开销。评论者提出,由于数据是线程本地的,是否可以使用非原子计数器来避免这种开销。
- 关键引用:
- "Swift uses automatic reference counting. It seems that it needs atomic operations that are expensive."(Swift使用自动引用计数,似乎需要昂贵的原子操作。)
- "Since the data is all thread-local, it should be possible to use non-atomic counters?"(由于数据是线程本地的,是否可以使用非原子计数器?)
项目背景与目标:
- 主要观点:该项目是更大规模计划的一部分,旨在构建一个能够渲染原生UI的Web浏览器,而不是传统的HTML渲染。项目使用Elixir构建无头浏览器,并通过disterl与SwiftUI渲染器通信。
- 关键引用:
- "This is an extraction for a much larger effort where we're building a web browser that can render native UI."(这是一个更大规模计划的一部分,我们正在构建一个能够渲染原生UI的Web浏览器。)
- "We communicate with the SwiftUI renderer via disterl."(我们通过disterl与SwiftUI渲染器通信。)
项目的技术实现与扩展性:
- 主要观点:项目通过虚拟DOM和Erlang进程实现UI渲染,并进一步将客户端JS库编译为WASM运行在无头浏览器中。项目支持多种SwiftUI目标,并计划扩展到其他语言。
- 关键引用:
- "We've built a virtual DOM where each node in the vDOM will have its own Erlang process."(我们构建了一个虚拟DOM,其中每个节点都有其自己的Erlang进程。)
- "Swift's portability means we should be able to bring this to other languages as well."(Swift的可移植性意味着我们也可以将其扩展到其他语言。)
项目的当前状态与未来计划:
- 主要观点:项目已接近集成阶段,即将进行基准测试和验证。项目最初是LiveView Native项目的一部分,但由于与上游项目的合作困难,决定扩大范围。
- 关键引用:
- "We're nearing the point of integration where we can benchmark and validate this effort."(我们已接近集成阶段,即将进行基准测试和验证。)
- "This originally started as the LiveView Native project but due to some difficulties collaborating with the upstream project we've decided to broaden our scope."(这最初是LiveView Native项目的一部分,但由于与上游项目的合作困难,我们决定扩大范围。)