协程不是系统级线程,很多时候协程被称为“轻量级线程”、“微线程”、“纤程(fiber)”等。简单来说可以认为协程是线程里不同的函数,这些函数之间可以相互快速切换
协程也叫微线程,英文名称为coroutine。一个进程可以有多个线程,一个线程可以有多个协程,这是协程和线程间的关系。不同的是,线程由系统调度,但协程需要自己调度,协程运行在用户态。
0x00 TL;DR 上⼀篇⽂章中已经简单介绍过了CET的基本原理和实际应⽤的⼀些技术,站在防守⽅的视⻆下,CET确实是⼀个能 ⽐较有效防御ROP攻击技术的措施。那么在攻击者的视⻆来看,研究清楚CET的技术细节,进⽽判断CET是否是⼀ 个完美的防御⽅案,还是存在⼀定的局限性,则是攻击⽅的重中之重。 本⽂由浅⼊深地讲述CET的实现细节,最后提出⼏个理论可⾏的绕过⽅案,供研究者参考。 0x01 Shadow Stack Overview 上⼀篇⽂章已经⼤概对CET做了个基本概念介绍,所以就不重复,直接说重点。
C++20推出了官方的协程库,但是在此之前C++并没有提供协程语法。libco是经典的C++协程库,本文将从源码角度分析libco,并参考了原作者的文章。
glibc提高的功能类似早期setjmp和longjmp。本质上是保存当前的执行上下文到一个变量中,然后去做其他事情。在某个时机再切换回来。从上面函数的名字中,我们大概能知道,这些函数的作用。我们先看一下表示上下文的数据结构(x86架构)。
In a System V-like environment, one has the type ucontext_t defined in <ucontext.h> and the four functions get-context(2), setcontext(2), makecontext() and swapcontext() that allow user-level context switching between multi-ple threads of control within a process.
作者:kylinkzhang,腾讯 CSIG 后台开发工程师 什么是协程 我们可以简单的认为:协程就是用户态的线程,但是上下文切换的时机是靠调用方(写代码的开发人员)自身去控制的。 同时,协程和用户态线程非常接近,用户态线程之间的切换不需要陷入内核,但部分操作系统中用户态线程的切换需要内核态线程的辅助。 下面是一个简单的例子: void A() { cout << 1 << " "; cout << 2 << " "; cout << 3 << " "; } void B() {
This function transfers control to the context in ucp. Execution continues from the point at which the context was stored in ucp. setcontext does not return.
error:Build input file cannot be found:‘/Users/.../Libraries/WebSocket/libfishhook.a’__
随着Golang的兴起,协程尤其是有栈协程(stackful coroutine)越来越收到程序员的关注。协程几乎成了程序员的一套必备技能。
libcopp很早就实现完成了v2版本,现在迁移进atsf4g-co/tree/sample_solution以后也把v2分支正式并入了主干。原来的版本切出到v1分支并且停止维护了。
libco是微信后台开发和使用的协程库,同时应该也是极少数的将C/C++协程直接运用到如此大规模的生成环境中的案例了。
编译环境 Ubuntu 16.04 x86_64 arm-xm-linux.tar.gz 下载openssl源码 $ wget https://www.openssl.org/source/openssl-1.1.0d.tar.gz 解压源码 $ tar xvf openssl-1.1.0d.tar.gz 执行Configure脚本 $ cd openssl $ ./Configure linux-generic32 \ no-shared \ no-asm \ no-async \ --pre
昨天写完了 Wasmer PR #489 Su Engine 的实现。这个 PR 的核心功能是对 WebAssembly JIT 编译后代码运行状态的读取、解释和构造。以此为基础,我们可以实现一些有用的功能:
前面我们已经了解到协程的基本概念以及对称协程和非对称协程的定义,本节将对如何用c语言在用户态实现协程切换作以简单介绍。
前段时间有同事联系我想看看可能推广我之前写的协程库 libcopp,虽然 libcopp 已经用到过好几个项目上,这几年也断断续续地写了一些实现细节的文章,但是也但确实需要系统、概览性地介绍下 libcopp ,所以就有了这篇文章。
服务器并发场景是在程序IO密集型有优势。因为IO操作速度远没有CPU的计算速度快。程序阻塞IO将浪费大量CPU时间。程序计算密集型的,并发编程反而没有优势。
简介 在上一篇文章 《微信终端自研C++协程框架的设计与实现》 中,我们介绍了异步编程的演化过程和 owl 协程的整体设计思路,因篇幅所限,上文中并没有深入到协程的具体实现细节。用 C++ 实现有栈协程,核心在于实现协程上下文切换,在 owl 协程的整体架构中,owl.context 位于最底层,所有上层 API 全部基于这一层来实现: 本文将详细讲解 C++ 协程上下文切换的底层原理,手把手教你从零开始实现 C++ 协程。 owl.context 接口设计 业界比较有名的上下文切换库有 uconte
后台架构的微服务化,原先的单体应用被按照功能模块切分为若干进程组承担,此种架构演化带来的收益诸如:
之前写了 《协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比》 和 《C++20 Coroutine》 ,但是一直没写 C++20 Coroutine 的测试报告。
研发人员在遇到线上报警或需要优化系统性能时,常常需要分析程序运行行为和性能瓶颈。Profiling技术是一种在应用运行时收集程序相关信息的动态分析手段,常用的JVM Profiler可以从多个方面对程序进行动态分析,如CPU、Memory、Thread、Classes、GC等,其中CPU Profiling的应用最为广泛。
这里是 HelloGitHub 推出的《讲解开源项目》系列,本期为您讲解的是 80、90 后儿时的记忆,诞生于 1978 年的经典街机游戏《太空侵略者》也叫“小蜜蜂”的 C 语言复刻版——si78c。
本文介绍了JVM平台上CPU Profiler的实现原理,希望能帮助读者在使用类似工具的同时也能清楚其内部的技术实现。
协程可以说是 golang 中的有名的框架,本文主要分析 Github 项目 Ntyco 协程框架的实现,由于本人目前 golang 写的不多,因此不会对 golang 的源码进行分析,只是根据 golang 的协程调度来分析 c 语言版本调度。
首先对于游戏的业务,一般是玩家登陆到大厅,有一些任务、物品、好友、排行榜、聊天这种交互,其次是玩家与玩家之前的匹配与对局。以Moba游戏为例,玩家主要的行为就是登陆后进行匹配,匹配到水平差不多的10个人,分为两队,每组5个人创建对局进行pvp战斗,玩家的操作以指令的方式由客户端发到服务器。 大厅中客户端与服务器的连接是TCP连接,对局中玩家的操作更关注实时性,一般的用可靠UDP进行通信。
在liunx系统中 没有进程和线程的区别 统称 “task” 进程标志(task_struct) 进行统一描述
在 Rust 中使用 nix 这个库,在某些情况下可以简化 Unix 系统编程。本文主要包括以下内容:
rdma_rxe 内核模块提供 RoCEv2 协议的软件实现。 RoCEv2 协议是存在于 UDP/IPv4 或 UDP/IPv6 之上的 RDMA 传输协议。 InfiniBand (IB) 基本传输标头 (BTH) 封装在 UDP 数据包中。 创建 RXE 实例后,通过 RXE 进行通信与通过任何 OFED 兼容的 Infiniband HCA 进行通信相同,尽管在某些情况下会涉及寻址问题。 特别是,虽然 GRH 标头的使用在 IB 子网中是可选的,但对于 RoCE 来说是强制性的。 基于 IB 动词编写的动词应用程序应该可以无缝工作,但它们需要在创建地址向量时提供 GRH 信息。 修改库和驱动程序以提供硬件所需的从 GID 到 MAC 地址的映射
http://www.csdn.net/article/2014-06-27/2820432
协程又可以称为用户线程,微线程,可以将其理解为单个进程或线程中的多个用户态线程,这些微线程在用户态进程控制和调度.协程的实现方式有很多种,包括
过年啦,最近在看一些非技术性的东西,Anna 的Paper也还没看完。随手优化了下Blog的主题,修复和优化了一些小问题。然后来Merge了一下 boost.context 最新 1.69.0 版本的asm部分到 libcopp。
有栈协程是基于函数切换上下文恢复的思路实现被中断协程的继续执行,但是这个上下文里面有返回地址,即下一条指令的地址,所以当程序发生改动重新编译生成,指令地址有可能发生改变,这种对于需要重新编译生成发布的发布场景支持并不友好,会因为程序指令地址的变化导致协程执行流的错乱。这时另外一种不基于上下文恢复的协程机制提供了一种新的思路。
前面介绍了协程的基本概念和协程切换的常见方式以后,本文将介绍如何通过c语言实现自己的协程库,分为独立栈和共享栈两种实现,代码见git仓库。
coroutine库是云风大佬以前写的一个协程库,短小精悍,源码分析在这(https://github.com/theanarkh/read-coroutine-code)。今天就分析一下这个库的原理。话不多说,直接开始。 首先了解一下数据结构。
本文是『张涛的NDK之旅』,本来很早以前就有很多读者希望我能写一些关于MDK的文章,但是由于我本身对NDK不熟悉,所以找来了同事张涛的文章。欢迎大家关注他的博客——开源实验室(点击原文链接可以直接访问)
【每日一语】绝对不要做你的敌人希望你做的事情,原因很简单,因为敌人希望你这样做。——拿破仑
C++协程一直是大家比较关注的一个技术点, 在C++20 coroutine属性正式推出之前, 就已经有很多项目实装了, 实现机制也略也差异, 下面先来简单看下比较常见的实现方式:
网上看到一个很有意思的美团面试题:为什么线程崩溃崩溃不会导致 JVM 崩溃,这个问题我看了不少回答,但发现都没答到根上,所以决定答一答,相信大家看完肯定会有收获,本文分以下几节来探讨
其中sigreturn是一个系统调用,在类unix系统发生signal时候会被间接地调用。
内核维护着各种统计信息,被称为Counters,用于对事件进行计数。例如,接收的网络数据包数量,发出的磁盘I/O请求,执行的系统调用次数。常见的这类工具有:
前言:CPU Profiler 是应用性能诊断和优化的利器,本文介绍 V8 中关于这部分的实现,细节比较多也比较复杂,大致分析一下原理,代码来自 V8 10.2。
=============================================================================
在多线程编程和并发处理中,我们经常会听到进程、线程、协程、纤程和Virtual Threads这些概念。虽然它们都与并发编程相关,但很多人对它们的区别和关系并不清楚。本文将深入解析进程、线程、协程、纤程和Virtual Threads之间的区别与关系,帮助读者更好地理解并发编程的不同概念。
为了打造高性能的服务器,通常思路有两种:1.多cpu利用,并发执行,如多进程和多线程 2、提高每个cpu的使用率,让每个cpu高效起来。
我们知道Java崩溃是在Java代码中出现了未捕获异常,导致程序异常退出,常见的异常有:NPE、OOM、ArrayIndexOutOfBoundsException、IllegalStateException、ConcurrentModificationException等等。 还有一类崩溃,也是我们不得不关注,那就是Native层崩溃,这类崩溃不像Java层崩溃那样比较清晰的看出堆栈信息以及具体的崩溃。每当遇到是都要查找分析,写这篇的目的是帮助自己做下记录,也希望能帮到有类似困扰的你,下面我们开始一起学习实践吧。 本文学习实践的demo以张绍文《Android开发高手课》中的例子进行。
我们线上的业务 jar 包基本上普遍比较庞大,动不动一个 jar 包上百 M,启动时间在分钟级,拖慢了我们在故障时快速扩容的响应。于是做了一些分析,看看 Java 程序启动慢到底慢在哪里,如何去优化,目前的效果是大部分大型应用启动时间可以缩短 30%~50%
C++ 在互联网服务端开发方向依然占据着相当大的份额;百度,腾讯,甚至以java为主流开发语言的阿里都在大规模使用C++做互联网服务端开发,今天以C++为例子,分析一下要支持协程,需要考虑哪些问题,如何权衡利弊,反过来也可以了解到协程适合哪些场景。
从后台工程师的角度说,有栈协程的应用更普遍。例如,云风封装的非常经典的基于C的ucontext.h来实现的共享栈的协程,具体请见《C 的 coroutine 库》。而golang在语言级实现的协程是独立栈的协程。
领取专属 10元无门槛券
手把手带您无忧上云