dotnetCampus.Ipc icon indicating copy to clipboard operation
dotnetCampus.Ipc copied to clipboard

本机内多进程通讯库

Results 11 dotnetCampus.Ipc issues
Sort by recently updated
recently updated
newest added

如题,编译项目出现此问题,如何解决

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 并发送消息