问题标签 [green-threads]

I have a Django/Tastypie app where I've monkey patched everything with eventlet.

I analysed performance during load tests while using both sync and eventlet worker clasees for gunicorn. I tested against sync workers to eliminate the effects of waiting for other greenthreads to switch back, and I found that the memcached calls in my throttling code only take about 1ms on their own. Rather than switch to another greenthread while waiting for this 1ms response, I'd rather just block at this one point. Is there some way to tell eventlet to not switch to another greenthread? Maybe a context manager or something?

要M:N在 Rust 中使用线程模型，我会启动一个池，然后像往常一样开始生成任务。 绿色文档给出了以下示例：

如果您想动态添加另一个操作系统线程，可以执行以下操作：

有没有办法说使用 x num 个 OS 线程，还是必须在代码中创建和管理它们？

In my Python program, I use eventlet to create a lot of greenthreads, just want to know if the current greenthread sleeps, which one of the rest will get scheduled and run? Any scheduler in the eventlet?

Thanks!

我正在研究使用 LLVM 作为本机代码生成器来设计一种支持轻量级进程（“绿色线程”）的并发语言。轻量级进程以 M:N 方式分配给本地操作系统线程，并且线程之间的工作窃取应该是可能的（即进程应该由可以在必要时在线程之间传递的数据结构表示）。可能同时存在大量进程，因此进程不应占用太多内存，并且它们之间的上下文切换应尽可能快。此外，在上下文切换期间或发生垃圾收集时“暂停”轻量级进程应该相当简单。我知道 Erlang 有一个 LLVM 后端，但我几乎找不到关于它的实现的文献；

考虑在每个请求都由用户级线程 (ULT)（绿色线程/erlang 进程/goroutine/...任何轻量级线程）处理的平台上构建 Web 应用程序。假设每个请求都是无状态的，并且在应用程序启动时获取数据库连接等资源并在这些线程之间共享。这些线程中的垃圾收集需要什么？

通常这样的线程运行时间很短（几毫秒），如果设计良好，不会使用超过几个（KB 或 MB）的内存。如果线程中分配的资源的垃圾收集是在线程退出时完成的并且独立于其他线程，那么即使是第 98 个或第 99 个百分位的请求也不会出现 GC 暂停。所有请求都将在可预测的时间内得到答复。

这种模型有什么问题，为什么没有被广泛使用？

运行时自由：Rust 的运行时系统和绿色线程模型已被完全删除，这将“hello world”的静态二进制大小减少了一半，并为标准库的低级挂钩打开了大门。由 Aaron Turon 实施。

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

绿色线程模型的缺点是什么？

为什么 Erlang 这么快？

http://eventlet.net/doc/patching.htm中的文档 说“如果没有指定参数，则所有内容都已修补。” 和“线程，它修补线程、线程和队列”。

但是通过一个简单的测试：

结果是：

似乎线程根本没有修补。医生有错吗？

此代码不打印任何内容：

但是这段代码会打印数字：

唯一的区别是pool.waitall()。在我看来，waitall()这意味着等到池中的所有绿色线程都完成工作，但是无限循环等待每个绿色线程，所以pool.waitall()没有必要。

那么为什么会这样呢？

参考：http ://eventlet.net/doc/modules/greenpool.html#eventlet.greenpool.GreenPool.waitall

我们有一个使用 Eventlet 模块的现有项目。

有一个服务器使用绿色线程处理客户端请求。所有请求均由单个用户“用户 A”处理

我现在需要更改它以在线程上执行 setfsuid/setfsgid，以便所有底层文件都由请求用户的所有权创建。

我知道我需要 setid Linux 功能来进行 setfsid 调用。

但是 setfsid 调用会像使用原生线程一样使用绿色线程吗？

通过阅读网上有关“绿色线程”的各种文本，我无法收集到太多信息：（

我正在对 C++ 绿色线程进行一些研究，主要是boost::coroutine2类似的 POSIX 函数makecontext()/swapcontext()，并计划在boost::coroutine2. 两者都需要用户代码为每个新函数/协程分配一个堆栈。

我的目标平台是 x64/Linux。我希望我的绿色线程库适用于一般用途，因此堆栈应根据需要扩展（合理的上限很好，例如 10MB），如果未使用太多内存时堆栈可以收缩（不需要），那就太好了）。我还没有找到合适的算法来分配堆栈。

经过一番谷歌搜索，我自己想出了几个选项：

1. 使用编译器实现的拆分堆栈（gcc -fsplit-stack），但拆分堆栈有性能开销。由于性能原因，Go 已经远离了拆分堆栈。
2. 分配一大块内存，mmap()希望内核足够聪明，不分配物理内存，只在访问堆栈时分配。在这种情况下，我们受内核的支配。
3. 预留一个大的内存空间mmap(PROT_NONE)并设置一个SIGSEGV信号处理程序。在信号处理程序中，当SIGSEGV由堆栈访问引起时（访问的内存在保留的大内存空间内），分配所需的内存mmap(PROT_READ | PROT_WRITE)。这是这种方法的问题：mmap()不是异步安全的，不能在信号处理程序中调用。它仍然可以实现，但非常棘手：在程序启动期间创建另一个线程用于内存分配，并用于pipe() + read()/write()将内存分配信息从信号处理程序发送到线程。

关于选项 3 的更多问题：

1. 我不确定这种方法的性能开销，当内存空间由于数千次mmap()调用而极度碎片化时，内核/CPU 的性能如何？
2. 如果在内核空间中访问未分配的内存，这种方法是否正确？例如，何时read()调用？

绿色线程的堆栈分配还有其他（更好的）选项吗？在其他实现（例如 Go/Java）中如何分配绿色线程堆栈？