首页
学习
活动
专区
工具
TVP
发布

蓝天

专栏作者
526
文章
820072
阅读量
41
订阅数
Linux下的strerror是否线程安全?
man strerror即可看到相关说明,strerror_r是线程安全的,但不带_r的strerror是非线程安全的。
一见
2019-03-14
1.2K0
“杀毒软件评测事件”显露360厚颜无耻的一面
2015/5/2日:三大杀毒软件评测机构宣布除名360,同时作废360在2015的所有评测结果(这一天,360官网还挂着荣获2015年4月的评测冠军的荣耀) 2015/5/3日:360声明传统杀毒评测标准落后云时代,我们正式退出AV-C   不说“AV-C、AV-TEST、VB100”三大杀毒软件评测机构是说对,360就毫无资格说,原因是在此事件之前,360一直拿评测结果做炫耀,既然心底这么不服,为啥还要拿着去炫耀。 而且评测机构说得非常在理,360自研的引擎QVM根本没参加评测,却在官网宣称360公司自主研发的QVM人工智能引擎以18分的满分夺冠,这需要多厚的脸。360送去参与评测的实际是来自罗马尼亚的Bitdefender(比特梵德),而这个引擎默认实际是关闭的,若使用这个引擎,360就没那么好采集用户数据了。 “国情不同”这种招数360都使得出来,另一面见证了360脸皮之厚。三大杀毒软件评测机构宣布除名360,而360却大义凌然声明退出评测,这样的公司存在也真是奇葩。 360说评测标准落后,既然如此,事发之前为啥拿着评测结果炫耀了?为啥还厚颜无耻的送去测评?事发,狰狞的一面才栩栩如生的显露出来。 360一定程度上推动了杀毒软件免费,但其实在360之前就有免费的小红伞和Avast等优秀的免费杀毒软件。这种江湖地位不如小米更为实在,小米拉低了手机、电视盒子、充电宝、智能手环等众多硬件的价格,影响不在同一个等级。
一见
2019-03-14
1.2K0
同时具备多线程和多进程安全的写日志工具
接口请浏览:https://github.com/eyjian/mooon/blob/master/mooon/include/mooon/sys/log.h 实现头文件请浏览:https://github.com/eyjian/mooon/blob/master/mooon/include/mooon/sys/safe_logger.h 测试代码:https://github.com/eyjian/mooon/blob/master/mooon/test/sys/test_safe_logger.cpp 使用示例: MYLOG_DEBUG("[%d]MMMMM", 2015); 支持自动添加换行符,默认会自动添加换行符,但可以禁止自动添加换行符。还支持自动在行尾添加点号等功能。 下面是实现:
一见
2018-08-10
7650
UniqGenerator - 生成唯一ID技术方案
UniqGenerator提供一个简单、可靠、高效的、可支撑大容量和大并发的取绝对唯一ID(可以是数字型的,也可以是字符串型的)的通用机制,这里讲的“绝对”是指在同一系统内部的绝对唯一,有别于UUID(通用唯一识别码,Universally Unique Identifier)。
一见
2018-08-10
9170
软件开发心得点滴记录
自从2002年大学毕业后一直沉浸于软件开发之路,平时喜欢思考和归纳,时常会产生一点心得和想法,回想起来是一笔宝贵的财富,只可惜陆陆续续遗忘了。今天立此文章,希望从今以后可以记录下,以帮助自己不断地提升,同时也作为一种纪念。
一见
2018-08-07
4360
多写引发的思考
如果是3个Master,采用2PC保证一致性,单个Master故障,会导致不可写。如果正提交的是一个大数据,会造成较大影响。实际上,这个时候可以允许提交,在故障Master恢复后,再同步数据到它上面,但是这个时候的数据对外是不可见的,因此不会影响数据的安全。
一见
2018-08-07
2550
优雅的让一个类在线程安全和线程非安全间切换
一个良好的多线程库,不应当一刀切的全加锁。因为有些时候,虽然是多线程环境,但可能依照设计一个类只会被一个线程操作,这个时候加锁是多余的,纯浪费性能,但另一些场景又需要它是线程安全的。
一见
2018-08-07
3620
设计mooon调度器遇到的难题
进程模型是指内核为一个独立的进程,而每个业务又为独立的一个进程,业务可以为多线程,同时内核会产生相应个数的内核线程与业务线程一一对应,内核线程和业务进程在创建业务时产生。
一见
2018-08-07
2990
如何解决fd跨线程安全问题
fd跨线程是不安全的,当一个线程close它后,就相当于成了野指针,另一线程再使用就成了对野指针的使用,当系统调用使用一个已经close后的fd时,可能出现内核报错,如果安全使用它了?有两个办法:一是对fd进行再包装,产生应用对象,对象通过引用计数保证线程安全;二是dup,直接对fd引用计数,使不同fd指向同一个内核对象,不同线程持有的fd值将不相同,线程只close自己的,实际就是引用计数减一。采用这两种方法,都可以保证fd跨线程安全。
一见
2018-08-07
3080
使用可重入函数进行更安全的信号处理
在早期的编程中,不可重入性对程序员并不构成威胁;函数不会有并发访问,也没有中断。在很多较老的 C 语言实现中,函数被认为是在单线程进程的环境中运行。
一见
2018-08-07
1.5K0
Ssh,scp自动登陆方法
Ssh,scp自动登陆方法 ########################### A为本地主机(即用于控制其他主机的机器) ; B为远程主机(即被控制的机器Server), 假如ip为192.168.60.110; A和B的系统都是Linux 在A上运行命令: # ssh-keygen -t rsa (连续三次回车,即在本地生成了公钥和私钥,不设置密码) # ssh root@192.168.60.110  "mkdir .ssh; chmod 0700 .ssh" (需要输入密码) # scp ~/.ssh/id_rsa.pub  root@192.168.60.110:.ssh/id_rsa.pub (需要输入密码) 在B上的命令: # touch /root/.ssh/authorized_keys2 (如果已经存在这个文件, 跳过这条) # cat /root/.ssh/id_rsa.pub  >> /root/.ssh/authorized_keys2 (将id_rsa.pub的内容追加到 authorized_keys2 中) 回到A机器: # ssh root@192.168.60.110 (不需要密码, 登录成功) 如果能保护好自己的私钥, 这种方法相对在shell上输入密码, 要安全一些 ############################################## 深入一点点: 从表面上简单的理解一下登录的过程, 首先 ssh-keygen -t rsa 命令生成了一个密钥和一个公钥, 而且密钥可以设置自己的密码,可以把密钥理解成一把钥匙, 公钥理解成这把钥匙对应的锁头,把锁头(公钥)放到想要控制的server上, 锁住server, 只有拥有钥匙(密钥)的人, 才能打开锁头, 进入server并控制,而对于拥有这把钥匙的人, 必需得知道钥匙本身的密码,才能使用这把钥匙 (除非这把钥匙没设置密码), 这样就可以防止钥匙被人配了(私钥被人复制) 当然, 这种例子只是方便理解罢了, 拥有root密码的人当然是不会被锁住的, 而且不一定只有一把锁(公钥), 但如果任何一把锁, 被人用其对应的钥匙(私钥)打开了, server就可以被那个人控制了 所以说, 只要你曾经知道server的root密码, 并将有root身份的公钥放到上面, 就可以用这个公钥对应的私钥"打开" server, 再以root的身分登录, 即使现在root密码已经更改! 如果想控制n个机器, 那就需要n对钥匙(密钥和公钥), ssh-keygen 命令可以随意更改钥匙对的名字, 比如: [root@wwy .ssh]# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/id_rsa_192.168.102.12 ...... 这样私钥和公钥的名字分别就是: id_rsa_192.168.102.12 和 id_rsa_192.168.102.12.pub 然后将 id_rsa_192.168.102.12.pub 文件的内容, 追加到sever的 ~/.ssh/authorized_keys2 文件中, 最后, 在本地用ssh命令的 -i 参数指定本地密钥, 并登录: # ssh -i /root/.ssh/id_rsa_192.168.102.12  192.168.102.12 如果密钥设置了密码, 就用密钥的密码登录, 没设密码, 就直接登录进去了 scp也是一样的 如: scp -i /root/.ssh/id_rsa./xxx  192.168.102.158:/home/wwy/bak
一见
2018-08-07
8510
Linux系统命令Top/free的使用及参数详解
top [-] [d delay] [q] [c] [S] [s] [i] [n]
一见
2018-08-07
8430
电信系统架构方案
撰文/青润(本文来自《程序员》杂志2003年3期) 国内软件业曾有人对行业性软件进行划分,在几个较大的行业中,排行前几位的分别是:通信、电力、金融…… 但从对技术的要求与和安全性的要求上来说,通信行业的计费和金融行业的交易都是并称的。因此在通信行业软件形成之初,计费就成为了通信行业的核心软件,能否有实力作计费软件成为在行业中是否具有实力的标志。于是也就形成了中国通信行业著名的“九七”工程!这是完成电信行业核心业务层面的信息化工程。 继“九七”工程之后,2001年,中国的各电信公司根据国外电信公司的信息化进程和经验,总结提出要建立中国电信公司的运营支撑系统,这个系统是基于“九七”工程外围的运营支撑业务构建起来的,如果说“九七”工程是心脏,那么运营支撑系统就是四肢!心脏是为了提供肌体的动力,四肢才可以通过各种形式来获取利益,使心脏能继续生存下去。运营支撑系统在中国电信集团公司被称为“OSS”系统,全称是“Operation Support System”,在中国移动通信集团称为“BOSS”系统,全称是“Business and Operation Support System”。 在电信集团提出构建运营支撑系统的同时,各电信分公司还在筹划构建符合自己特点的ERP系统,与此同时,基于运营支撑系统之外的各种行业业务系统也开始了开发与规划。 电信行业软件历程 一、九七工程 九七工程是中国通信行业软件最初的形象。实际上在实施九七工程的时候,中国的通信行业基本上还是一家垄断的状态,那就是中国电信! 九七工程主要解决了电信行业最迫切需要解决的交换、计费、帐务、经营等最关键的业务过程。这些业务要求实时性非常强、对准确性的要求也非常高,因为系统的每一个数据都关系到电信的直接收入。 一些国内的软件公司借着这股春风发展了起来,也有一些公司从此开始涉足软件行业。 从技术和行业的应用成熟度来说,当时进行这项工程的条件是不具备的,但是,这项工程的实施却是必须的。所以,在实施这个工程的过程中,不少系统都是多次返工,虽然达不到实际意义上的7×24,但是至少可以得到比其他方式更精确的数据信息,这也就是这项工程的一大意义了。因此,在此后,尽管1997年早成为过去,但是九七工程这个名词却一直被沿用下来,以代表这个特殊的意义——中国电信行业的第一次信息化。 二、OSS/BOSS系统 2001年,中国移动开始规划“BOSS”系统,2002年各省移动公司分别制定了自己的“BOSS”系统的技术规范和业务规范,但是,离真正实施还有一段时间,因为中国移动还需要进行统一的规划。 在中国移动制定规范的同时,中国电信集团也不甘落后,也开始制定自己的“OSS”系统的规范和实施规划,并在其上海研究院进行相关的试验。不过,因为其工作量过大,按照初步的估计,一个省级电信公司要实现“OSS”系统的规划,至少需要五年,投入至少有3到5亿以上的资金。按照这样的估算,中国电信集团要实现全国的“OSS”规划至少就需要90亿以上的资金投入,所以,一直到现在,中国电信集团的“OSS”系统还仍然无法进入实施阶段。 其他的电信运营商,诸如中国联通、中国网通、中国铁通等公司也都在纷纷筹划自己的相关系统。 技术方案概述 一、B/S结构 随着软件技术和网络的发展,各种行业软件业几乎都在进行着B/S与C/S结构的争论和演化。虽然大家都认为B/S结构更先进一些,但是,在某些特定的行业和业务中,C/S结构的系统仍然有着非常重要的地位和不可替代的作用。 加上B/S结构产品的开发难度要远大于C/S结构的系统,调试和测试工作都要比C/S结构的产品复杂得多。在此条件下,基于成本和效益的各种方案对此有很大的影响。 经过长时间的研究和探讨,通信行业的产品在体系结构上基本达成一致:在业务操作实现领域采用B/S结构,在某些特殊的功能实现上适当地采用C/S结构。 二、多层结构选择的必然 提到体系架构的选择,电信行业的大多数业务对系统的实时性、稳定性要求都非常高,因此电信行业软件业就成了所有软件中开发难度最大的一种。 目前国际上流行的两种软件体系,都采用了多层体系来进行大中型系统和关键系统的构架。 电信行业项目的实施中,也大都采用了中间件进行整个体系的构架,在J2EE体系成型之前,大多数系统都采用C/C++进行开发,一些关键的业务实现则采用 Corba体系。随着Corba与J2EE的融合,两大对立阵营的.Net与J2EE逐渐成型,电信领域的大型系统大部分都采用了基于Java的多层体系架构。如图2所示:
一见
2018-08-07
3.8K1
Linux find命令详解
find pathname -options [-print -exec -ok ...]
一见
2018-08-07
3.8K0
redis for lack of backlog
版本: redis-3.2.9 部署: 5台64G内存的物理机,每台机器启动2个redis进程组成5主5备集群,每台机器1个主1个备,并且错开互备。 问题: 发现redis进程占用内存高达40G,而且全是备进程。尝试通过重启进程方式释放内存,但进入复制死循环,报如下所示错误: for lack of backlog (Slave request was: 51875158284) 通过网上查找资料,修改client-output-buffer-limit和repl-timeout值,问题未能得到解决,仍然报for lack of backlog,并仍然循环复制。 move备进程的data目录,但保留nodes.conf文件,然后再重启,这次重启成功。采取同样方法处理其它备进程,同样成功,内存同样降到和主进程接近的大小10G。 待分析:为何备进程占用的内存是它的主进程的4倍(分别40G和10G)?除了上述方法外,是否有其它更安全可靠的释放办法?
一见
2018-08-02
3830
没有更多了
社区活动
Python精品学习库
代码在线跑,知识轻松学
【玩转EdgeOne】征文进行中
限时免费体验,发文即有奖~
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·干货材料·成员作品·最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档