递归火山软件开发平台

标题: . [打印本页]

作者: server 时间: 2023-5-31 20:04
标题: .
本帖最后由 server 于 2023-6-2 00:57 编辑

.

作者: 雨中漫步 时间: 2023-5-31 20:21
热更新的方式有很多，时间差只是其中之一，
并不是所有人都需要热更新，火山作为开发工具，不太可能为了部分人改太多
另外，你要的读写属性方法是不存在的，开发工具并不能确定是否可以安全卸载，特别是并发条件下，这是作者的工作。

作者: qaz2428119 时间: 2023-5-31 21:08
这是在讨论什么,什么热更新,
热更新,这玩意,可不简单,牵扯到的东西太多了,除非这个热更新的DLL或汇编代码,不是常用功能代码,不然热更新起来,基本和停止整个程序运转差不多

作者: 雨中漫步 时间: 2023-5-31 21:25

qaz2428119 发表于 2023-5-31 21:08
这是在讨论什么,什么热更新,
热更新,这玩意,可不简单,牵扯到的东西太多了,除非这个热更新的DLL或汇编代码, ...

能做到的，良好的结构设计和充分的模块化就可以。还提供了教程和例子，也不算难。
楼主已经接近理解了。
不过，高并发下，并没有他要的状态位，所以才使用时间差，估计理解还差一丝丝。

作者: 雨中漫步 时间: 2023-5-31 21:27

qaz2428119 发表于 2023-5-31 21:08
这是在讨论什么,什么热更新,
热更新,这玩意,可不简单,牵扯到的东西太多了,除非这个热更新的DLL或汇编代码, ...

教程在这里 http://gs.xieyoutx.com/t/t-tz-16 ... 8136758340598-.html

作者: 350246356 时间: 2023-5-31 22:55

雨中漫步发表于 2023-5-31 21:27
教程在这里 http://gs.xieyoutx.com/t/t-tz-16653838351264432922-24245167616237927859-192131681367583 ...

教程往B站上传一份吧有空晚上可以躺床上看！

作者: 明靓 时间: 2023-6-1 02:23
孟总的热更新思路,真心不错,让人眼前一亮.

这么久以来,看了一些孟总的教程,还有在他的大群里泡久了,学到很多东西,很多思路.

现在我的代码规范,基本是受到世恒老师和孟总的影响,真的很感谢!

作者: qaz2428119 时间: 2023-6-1 09:28

雨中漫步发表于 2023-5-31 21:27
教程在这里 http://gs.xieyoutx.com/t/t-tz-16653838351264432922-24245167616237927859-192131681367583 ...

如果是网页程序的热更新,到是与应用程序的热更新大不相同,他们的服务机制不同

作者: qaz2428119 时间: 2023-6-1 09:32

雨中漫步发表于 2023-5-31 21:25
能做到的，良好的结构设计和充分的模块化就可以。还提供了教程和例子，也不算难。
楼主已经接近理解了。
...

应用程序和网页程序,那不在一个级别上,无法一概而论,
应用程序,需要你自己实现所有功能,而网页程序游览器已经为你打好了所有基础

作者: 雨中漫步 时间: 2023-6-1 09:34

qaz2428119 发表于 2023-6-1 09:28
如果是网页程序的热更新,到是与应用程序的热更新大不相同,他们的服务机制不同
...

编程思想是想通的，其他程序结构合理也可以热更新，多数插件都是可以热更新的。不要固执了。
高并发都能热更新，普通程序只要规范接口就可以热更新，
相当于给你展示了一个高并发难度大的热更新，你却说，非并发的程序热更新做不到。

给你看了跑车，你却说自行车的事。

你再认真思考下，你认为的不行，就是结构设计和模块化能力不足而已。

作者: 雨中漫步 时间: 2023-6-1 09:39

qaz2428119 发表于 2023-6-1 09:32
应用程序和网页程序,那不在一个级别上,无法一概而论,
应用程序,需要你自己实现所有功能,而网页程序游览器 ...

WEB服务端是服务器执行，和浏览器没太大关系，服务端发送出去的页面才是浏览器处理

这里讨论的重点是多线程开发，多线程在多数语言中都是难度比较高的部分，

搞并发的热更新难度是比普通程序更高的，并不是低

并不是服务端程序简单，因为高并发的需求，难度更高。

你的认知有错误的地方，先思考再争论。

作者: 创世魂 时间: 2023-6-1 10:30
雨中漫步是真大佬，教程值得好好学习。

对于exe这种程序后台的热更新，确实有些麻烦，因为如果服务器存在高并发场景，热更新很可能会出现一些不可预料的问题。

作者: 199 时间: 2023-6-1 22:23
我现在都是用nginx，同时负载到exe1和exe2,当1关闭时，自动访问2，不知道这样有没有什么风险

作者: 雨中漫步 时间: 2023-6-2 00:49
本帖最后由雨中漫步于 2023-6-2 00:54 编辑

server 发表于 2023-6-2 00:07
编译的部件DLL，所有引用的部件方法进入和退出时，
使用原子递增和递减操作一个全局变量。

你所谓的原子锁也会影响性能，你有自信就搞出来测试看看再说，影响线程越多，负影响越大

例子里给出的方案是保持高并发的热更新，没有任何锁的影响。带锁的方案多了去了根本不需要讨论。

作者: 雨中漫步 时间: 2023-6-2 00:52

199 发表于 2023-6-1 22:23
我现在都是用nginx，同时负载到exe1和exe2,当1关闭时，自动访问2，不知道这样有没有什么风险 ...

讨论的是编译后的程序，并发环境，你讲的是多进程配合，不是同一个问题，两码事了。跑题了。

你当然可以俩进程切换，那就不是热更新了，而且俩进程无法同时刻独占同端口。

你把话题引向了多进程结构，可以多进程负载，那是另外的场景了。

作者: 雨中漫步 时间: 2023-6-2 00:55

server 发表于 2023-6-2 00:53
影响是一定的，
关于最优解，只能靠你们了。

你想简单，还想想性能没有损失，属于 想得美 哈哈哈

例子里的方案已经最简单的热更新方案，时间差都搞不定，其他方式就不用讨论了。方式的确还有好几种。时间差只是最简单的一个。

最简单的你都感觉麻烦就算了吧

作者: qaz2428119 时间: 2023-6-11 09:51

雨中漫步发表于 2023-6-1 09:34
编程思想是想通的，其他程序结构合理也可以热更新，多数插件都是可以热更新的。不要固执了。
高并发都能 ...

我不是说不能,只是它们两个不在一个服务体系里,难易程度没有可对比

作者: qaz2428119 时间: 2023-6-11 09:52

雨中漫步发表于 2023-6-1 09:39
WEB服务端是服务器执行，和浏览器没太大关系，服务端发送出去的页面才是浏览器处理

这里讨论的重点是多 ...

如果是服务端的热更新,那就当我没说

作者: server 时间: 2023-6-11 20:35

qaz2428119 发表于 2023-6-11 09:52
如果是服务端的热更新,那就当我没说

在他们面前，我们都是小白，白纸。我们安静就好了。

作者: 小蜗牛 时间: 2023-6-11 21:25

server 发表于 2023-6-11 20:35
在他们面前，我们都是小白，白纸。我们安静就好了。

是的..热更新的最优解其实并不是时间差,也不是原子锁...这些都是不靠谱的..最靠谱的是读写锁...
调用dll的时候读+1
释放dll..加载dll..就需要写+1

作者: qaz2428119 时间: 2023-6-16 09:55

小蜗牛发表于 2023-6-11 21:25
是的..热更新的最优解其实并不是时间差,也不是原子锁...这些都是不靠谱的..最靠谱的是读写锁...
调用dll ...

具体怎么做咱不知道, 只知道一点,加载与卸载,需要全局唯一,卸载后就必须不能读写,加载后才能读写

作者: server 时间: 2023-6-16 12:39
本帖最后由 server 于 2023-6-16 12:45 编辑

借鉴易语言包装子程序思路。
在不考虑极致速度情况下。

欢迎光临递归火山软件开发平台 (https://bbs.voldp.com/)