dotnetCampus.Ipc
dotnetCampus.Ipc copied to clipboard
本机内多进程通讯库
如题,编译项目出现此问题,如何解决
Automated PR to fix formatting errors
The following code does not use the new `IIncrementalGenerator` API, which leads to severe performance overhead when attempting to enable the source generator in IDE scenarios. https://github.com/dotnet-campus/dotnetCampus.Ipc/blob/d8b94a050a138b274b287b5e7e76409ac2dfb88b/src/dotnetCampus.Ipc.Analyzers/SourceGenerators/IpcShapeGenerator.cs#L75-L84 🔗 This issue...
用 ThreadLocal 的一个坑在于,线程的释放,在释放的时候,归还数组,将会遇到线程被干掉的异常
## 异常类型 * `IpcException` *抽象异常,永远不应该抛出,只允许被 `catch`* * `IpcRemoteException` *表示异常来自可正常连接并通信的其他端* * `IpcInvalidRemoteRequestException` *当 IPC 收到来自其他端的请求时,此请求无法被理解* * `IpcInvalidRemoteResponseException` *当 IPC 向其他端发起请求并收到其他端的响应后,此响应无法被理解* * 具体被序列化和反序列化的异常 *当其他端引发了异常,并通过 IPC 传过来时,此异常会被反序列化并重新抛出* * `IpcRemoteException` *当其他端引发了异常,并通过 IPC 传过来时,如果此异常无法被反序列化,则抛出此异常* *...
在 https://github.com/dotnet-campus/UnoSpySnoop 里将会尝试连接每个线程,每次连接失败时,都会存在管道没有释放 这是由于 Ipc 设计上是为了稳定性,尽量确保 Ipc 稳定连接,即使现在连接不上也会继续尝试连接。加上在尝试连接时是先启动自己的管道再尝试去连接对方,于是自己启动的管道等逻辑将会持续占用线程。在进行大量连接必定失败的 Peer 时,将会导致耗尽线程
在 Linux 下的 UOS 系统里面进行测试,如以下代码 ```csharp var peer = await ipcProvider.GetAndConnectToPeerAsync(args[0]); peer.MessageReceived += (sender, messageArgs) => { Console.WriteLine( $"[{Environment.ProcessId}] 收到 {peer.PeerName} 的回复消息:{Encoding.UTF8.GetString(messageArgs.Message.Body.AsSpan())}"); }; await peer.NotifyAsync(new IpcMessage("Hello", Encoding.UTF8.GetBytes($"Hello,进程号是 {Environment.ProcessId} 发送过来消息"))); Console.WriteLine($"[{Environment.ProcessId}]...
详: https://github.com/dotnet-campus/dotnetCampus.Ipc/issues/124#issue-1620294417
目前获取 IpcPubllic 接口是需要 PeerProxy 对象,但理论上来说 应仅需要 peerName 已经有足够条件获取 IpcPubllic 接口的代理对象了 简单想法 :获取 IpcPublic 接口代理对象的时候 存一份 IpcPublic 代理对象 和 peerName 的对照关系~ 在 CallMethodAsync 或者 CallMethod 的时候 去按对应关系 找到 PeerProxy 并发送消息