V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  neoblackcap  ›  全部回复第 29 页 / 共 99 页
回复总数  1972
1 ... 25  26  27  28  29  30  31  32  33  34 ... 99  
2019-09-02 16:30:44 +08:00
回复了 hanssx 创建的主题 Python celery worker 多线程执行完后卡住假死
@hanssx cpu 密集型是相对的,关键是你的任务类型不能堵塞整个处理逻辑,凡是耗时长的,不需要 IO 的任务都是 IO 密集型

看了一下你用 subprocess.Popen 去调用 nmap,你如果要改的话,请使用 gevent 的网络接口实现你 nmap 的功能,如果不会的话,此方法无解,你还是另寻他法吧。
2019-09-02 13:03:31 +08:00
回复了 EulerChen 创建的主题 Go 编程语言 Golang 如何写出同时包含字母和数字的正则?
\w*
有的,名校博士毕业证书就可以了。否则的话,看你所在公司以及岗位。当然你靠吹牛也不是不可能。考试认证是不可能考试的。本身该领域就属于前沿领域。方向对不对都不知道,怎么给你出题认证啊。大家都是靠刷论文跟学历
2019-09-02 12:38:10 +08:00
回复了 hanssx 创建的主题 Python celery worker 多线程执行完后卡住假死
没记错的话,celery 自身实现是对 fork 之类有限制的,所以你不应该在任务里面进行类似 fork 之类的操作,线程 pthread_create 同理了。
而且线程的支持我记得已经被 celery 自身抛弃的,所以应该是有缺陷的,建议不使用线程。

根据我以前的做法,我一般都是将网络 IO 与逻辑处理分离。celery 对 gevent 跟进程支持都相当好,因此我会选用个 gevent 处理所有网络 IO (网络 IO,通过 IO 复用,几百万个任务都可以轻松搞定,前提是不能有任何 CPU 密集型处理)。然后通过跟进程型任务结合,组成流水线,在 celery 对应 chain 操作。那么就可以稳定地运行。

因为 gevent 是处理网络是不堵塞的,所以你还是可以继续发任务给该 worker

可以参考一下
2019-08-19 00:58:31 +08:00
回复了 TangMonk 创建的主题 PHP 大家开发 PHP 的时候有没有一会儿开 Xdebug, 一会儿又关掉
@TangMonk pdb 是标准库的,不用额外安装
2019-07-29 11:18:00 +08:00
回复了 abcbuzhiming 创建的主题 Go 编程语言 请教, Go 是如何实现如此夸张的低的内存占用的?
jit 需要内存。至于相同的功能这个说法我表示怀疑。
GC 其实跟内存用多少关系不大。
2019-07-29 10:43:01 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@dbskcnc golang 作者原先就吐槽 C++的编译速度,因此他们坚持不能降低编译速度这个逻辑是自洽的。当然大家觉得好不好就另外一说。

不是说 go team 的经验足就代表他们比提案者厉害,有压倒性优势。大家都是受现代编译语言影响的人,提案者可不单单代表自己的知识储备,他还受这个业界最新的 PL 研究,多年来的 PL 实践影响。因此片面说其他人水平不够高是让人难以理解的。

其实不要说那么多,就是他们的追求跟大众的追求不协调而已。他们追求编译快速,自己觉得简单使用的语言,逻辑自洽。但是这说出来大家能接受吗?语言动了根本追求,哪怕是能做啊,那不就打了自己的脸?这才是根本问题。
2019-07-27 22:09:43 +08:00
回复了 linlance 创建的主题 Python Flask 只好放弃了, Django 拿起。。。其实我很喜欢 Flask。。。
@linlance 如果我没记错的话,16 进制权限值这个说法不是很对。根据经验来看,这个应该是 bitmap,应该转化为二进制来看,一个位代表一个权限。
一般我们配权限的时候都是采取位操作的方法,比如 0x01 | 0x02 来实现两个权限的并集。权限应该是写成常量,用的时候用按位取或(bitwise or)
2019-07-26 11:28:49 +08:00
回复了 lastright 创建的主题 程序员 C++真的有那么不堪吗?
C++是不管怎么骂,在抽象与效率方面它都是顶尖的。关键是这个语言需要你了解很多知识才能避开那些坑。
为什么电脑存的是 01 的信息,你却能看到中文?这中间是不是有一个映射的过程?你理解的是中文,跟不理解电脑存的 01 信息,有没有关系?
你可以这样做,不过我觉得这个队列也不是很必要。
因为可以以用户积分排序,然后按照每居人数进行匹配。人数一旦满足,就由世界服务器将用户移交到游戏房间服务器,这时候用户也就不可能再排队了。
我记得拳头好像是这样设计英雄联盟的,你可以搜一下,我记得他们分享过他们的服务器架构。
你可以粗略地用两个 List 来表示这个过程,不过一般都是两个独立的模块,互不影响,中间是通过通讯来进行沟通的。房间可以固定也可以不固定,不过我觉得为了游戏体验,可以通过检测服务器配置进行预分配。
因为我也不是搞游戏服务器开发的,所以我也只能通过之前看到的文章告诉业界是怎么做的。我建议你最好先去读读别人是怎么设计的,GDC 上面有游戏开发的分享,各个游戏公司的技术博客好像一般也有提及。可能老了一些,不过你可以尝试去找找 EVE 他们的分享,还有魔兽世界,还有国内的云风。他们的经验都是很好的。不懂就先读,否则你造的东西真的会玩具。
@devh0407 你为什要存房间 ID ?房间应该是临时的,用完就删除或者回收了,房间我想不到为什么需要跟游戏之后的数据关联,哪怕是游戏回放功能都不需要房间 ID,你需要记录什么数据,就放在一个赛后记录表就可以了。
没看懂你这个历史战绩跟房间有什么关系
房间当然是临时的,这个根据服务器状况来分配创建,不是很好理解么?房间的信息都是存在服务器内存,不是很明白有什么存储影响。
你战绩系统,游戏结束之后入库就可以了,跟房间有什么关系呢?

PS:没玩过王者荣耀,不是很了解,只是根据之前观看的网游架构回答
我记得 signal 模块也是很简单地封装一下系统信号处理的回调而已。
你这样的情况啊,用 bpftrace 试试看看?
2019-07-17 20:20:20 +08:00
回复了 SsuchingYu 创建的主题 Go 编程语言 Go 社区否决了新的 try 语句提议
@secondwtq 我只是发了一次言,其实还好。我只是说明一下这东西的优势在哪里,为什么 Monad 是更好的异常处理而且。毕竟一次回复不仅仅是一个人看到。大家也可以看到。大家各取所需,觉得 golang 好的就继续写,觉得其他更好的就去写其他就好了。我觉得没什么必要纠结什么天下第一,毕竟电锯跟锤子不一样,CNC 机床也不能替代凿子。当然爱一样东西,自己能出力去让它变得更好,这样也不错。
2019-07-17 18:27:04 +08:00
回复了 Buffer2Disk 创建的主题 程序员 Python 和 Go 在循环时候的性能对比
@Buffer2Disk 本身集合一般就是用哈希表实现
2019-07-17 15:43:09 +08:00
回复了 Buffer2Disk 创建的主题 程序员 Python 和 Go 在循环时候的性能对比
@Buffer2Disk
简单的理解就是只是用其中迭代其中一个集合,然后判断一下这个元素是否在,每次查询是否在集合的操作是 O(1),n 个就是 O(n)
2019-07-17 15:21:07 +08:00
回复了 SsuchingYu 创建的主题 Go 编程语言 Go 社区否决了新的 try 语句提议
@xfriday rust 里面是学习 haskell 的 monad,除非你是消费以及最终求值的阶段,否则不会有人会去用 match 来处理错误。
rust 的错误处理最大的优势就是,之前步骤的异常,并不会影响你的业务逻辑,以及强制错误处理。你完全可以使用 and_then 或者 map 方法对一个 Result 进行结果转换,完全不用什么 match。?只是一个相对简洁的语法糖,就算不用 rust 也比现有的什么异常以及返回值优秀。
当然你不了解 monad,强制每一步都 match 一下,那就认为 rust 也是返回值吧。毕竟宝马跟单车都是靠轮子走的,而且都是圆的。
2019-07-17 00:31:32 +08:00
回复了 Buffer2Disk 创建的主题 程序员 Python 和 Go 在循环时候的性能对比
@Buffer2Disk 你每次调用 range 都要申请内存,创建一个列表啊,能快才奇怪。你用 top 来计算 CPU 耗时的方法本身就不对。
而且你只是判断一个元素是否在另外一个列表里面,你转成集合,用求交集的方法啊。那个才 O(n),你现在这个粗糙的实现方式可是 O(n^2)。
你觉得是循环在耗时,那么请你在 Python 里面创建好两个列表,然后再开始你的循环计时,而且停 5s 有什么用啊?你写日志不好么?
2019-07-17 00:10:08 +08:00
回复了 Buffer2Disk 创建的主题 程序员 Python 和 Go 在循环时候的性能对比
range 返回列表,耗时在这
1 ... 25  26  27  28  29  30  31  32  33  34 ... 99  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1281 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 23:21 · PVG 07:21 · LAX 15:21 · JFK 18:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.