GuuJiang 最近的时间轴更新
GuuJiang

GuuJiang

V2EX 第 58186 号会员,加入于 2014-03-14 16:18:47 +08:00
今日活跃度排名 5622
根据 GuuJiang 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
GuuJiang 最近回复了
6 天前
回复了 rationa1cuzz 创建的主题 问与答 一道需求引发的数学题
71
“每位老师最多评审 50 支团队”这个条件可以等价为每个老师手底下有 50 个苦逼研究生,当需要老师去评审的时候其实是派一个研究生去当枪手,且每个枪手只能用一次,为了结果最大化,采用贪心策略,每当需要一轮评审的时候从剩余研究生数最多的老师里选 7 个成团,于是问题进一步简化为了在一个 10*50 的矩阵里从左到右依次取 7 个元素,不够 7 个时折行,最多能取几次,最终简化成了 500/7
@xuanbg 要不你再好好想想?匹配的是子串,不是子序列
这其实是一个非常有意思的问题,不知道真实的密码锁是怎么实现的,但是假如让我来设计一个密码锁的话,我会采用下面的方案
当设置密码时,将设置的密码编译为一个 AC 自动机(当然由于只有一个关键词,所以实际退化成了 KMP,不过也可以支持多密码),这样每按一个键时实际是在自动机中进行转移,当到达终结状态时就开门,这有个巨大的好处,无论前面输入的无效内容有多长,都不会带来时间和空间上的额外开销,理论上可以支持的无效内容长度没有上限
假设密码锁真的采用了这样的方案,那么确实可以认为是明文存储的,虽然没有直接地存储密码本身,但是获得了完整的自动机等价于获得了密码,不过对于密码锁这种必需要物理接触才能使用的系统来说,直接暴力破坏恐怕都比试图读取存储要容易得多,所以是否明文存储已经不是那么重要了
那要不试试你们心目中的产品之神 telegram 呗?家里的老人,不会发文字,微信只拿来视频用,是直接点击任意一次通话的气泡方便还是选择菜单-“视频通话”方便?至少我用过的 IM 全都是这个逻辑
虽说在 v 站黑张小龙才是政治正确,但这个功能真的没什么黑点吧?系统通讯录的通话记录不也是一样的逻辑?对于一些经常视频很少发文字的联系人来说反而很方便
21 天前
回复了 zhoudaiyu 创建的主题 问与答 有几个关于 websocket 的疑问想问问大家
@zhoudaiyu 后者
21 天前
回复了 zhoudaiyu 创建的主题 问与答 有几个关于 websocket 的疑问想问问大家
@zhoudaiyu 你这样一说就明白你的疑惑来自哪里了,实际情况是,发送“握手”使用的那个 http 总得要先有个 tcp 连接对吧,姑且称他为 A,“握手”的请求并不是为了开启一个新的连接 B,而是接着使用 A,只不过在 A 上承载的应用层协议摇身一变切换为了 ws 协议了
21 天前
回复了 zhoudaiyu 创建的主题 问与答 有几个关于 websocket 的疑问想问问大家
1. 从历史进程来看,websocket 是晚于 http 诞生的,你想象下如果自己就是制定标准的那班哥们,现在面临一个新任务,需要设计一种浏览器能使用的,能够保持连接,且服务端能够主动发送数据的协议,那么你有两种选择,一种是基于 TCP 设计一个全新的协议,一种是看看能否在现有的 http 的基础上 hack 一下完成目标,于是一拍大腿,http 本来就基于 TCP,把这个现成的连接拿来用不就完事了,于是只需要设计出一种方法,通过一个 http 请求让双方都知道“现在我给你发了一个 http 请求,你处理完这个请求后咱们这次请求时使用的那个 TCP 连接先别关,且从现在开始,在这个连接上咱们开始玩一个新的协议,这个协议不如就叫它 ws 协议吧”,这就是第一个 http 请求里的“Connection: Upgrade”干的事,这样有个很大的好处,就是当服务端版本比较旧,还不支持 websocket 时,它收到的仍然是一个合法的 http 请求,只不过忽略了“Connection: Upgrade”而已,这样不会带来什么大的兼容性问题
2. 原因同上
3. 同上,这时候 nginx 相当于个中间人,于是它需要干两件事,一是自己处理“Connection: Upgrade”,将上游到 nginx 的连接切换为 websocket,二是把“Connection: Upgrade”忠实地传递下去,让下游能够处理,从而将 nginx 到下游的连接也切换为 websocket,当存在多级 nginx 时同理,每一级都要正确地完成这两件事,整个链条才能串起来
4. 是可以的,如果做 4 层转发那么上面完全透明,而如果是应用层,就像 nginx 这样,那就需要像上面提到的这样,不光耀转发 Upgrade,同时自己也需要能够响应 Upgrade
5. 在应用层最好不要随便使用“挥手”这个词,以免带来更多的误解,虽然我知道你真正想表达什么,答案也很简单,因为从处理完 Upgrade 那一刻开始,协议已经切换成 websocket 了
24 天前
回复了 AndyAO 创建的主题 问与答 在 Git 中 pretty 是什么意思?
就是字面意思“好看”啊,对人类友好的展示方案
拿 json 举例,未 pretty 的 json 全部挤在一行,因为计算机解析时只需要标记就够了,而经过 pretty 以后就加入了额外的换行、tab 等排列成我们常见的那个树形格式,换行和 tab 对于解析来说是并不需要的,单纯就是为了让人类更容易看
@coderstory 我来帮你翻译下你的问题吧
你的意思无非就是 B 唤醒 A 以后自己并不是马上进入 wait,而是继续执行,由别的条件来让 B 进入 wait,这段时间 A 和 B 是同时执行的,由此可以推论所有只用一把锁(此处指广义的锁,无论是 synchronized 、j.u.c.Lock 、单 Lock 多 Condition 等)的方案通通都是不可行的,这些方案实现的两个线程互相唤醒的效果从时间线上看都是交替执行,这里顺便纠正一下你以及楼里部分人对 wait/notify 的一个常见误解,并不是说 B 调了 notify/notifyAll 以后 A 就开始执行了,B 调 notify 仅仅是让 A 开始进入锁的竞争,直到 B 进入 wait 、或者结束执行等其它方式离开临界区,A 成功竞争到锁后才真正开始执行的
回到你的问题来,再结合你下面说的应用场景,我觉得这大概率是个 XY 问题,先不说“前端调试后端”这个是否有误入歧途,光说前面这个问题,站在 B 的角度,从宏观上来说,你真的关心在 B 从调了 notify 到 wait 的这段时间 A 是不是真的开始执行了吗?这个对 B 来说理应是作为黑盒无感知的才对,如果你对这个有刚需,非要他们有一段并行的时间,那么一定是哪里出了问题,不要继续花心思在解决 Y 问题上了
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1567 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 17:02 · PVG 01:02 · LAX 10:02 · JFK 13:02
♥ Do have faith in what you're doing.