python-stackless

What are the drawbacks of Stackless Python? [closed]

我只是一个虾纸丫 提交于 2020-04-05 07:01:23
问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 8 years ago . I've been reading recently about Stackless Python and it seems to have many advantages compared with vanilla cPython. It has all those

Eventlet or gevent or Stackless + Twisted, Pylons, Django and SQL Alchemy

[亡魂溺海] 提交于 2020-01-28 13:16:53
问题 We're using Twisted extensively for apps requiring a great deal of asynchronous io. There are some cases where stuff is cpu bound instead and for that we spawn a pool of processes to do the work and have a system for managing these across multiple servers as well - all done in Twisted. Works great. The problem is that it's hard to bring new team members up to speed. Writing asynchronous code in Twisted requires a near vertical learning curve. It's as if humans just don't think that way

Stackless in PyPy and PyPy + greenlet - differences

爷,独闯天下 提交于 2019-12-31 10:43:23
问题 New version of PyPy ships with integrated Stackless . As far as I know the bundled Stackless is not the same as the origin Stackless from 2001 with continuations. So mainly it is the green threads framework with dispatcher. Greenlet is a spin-of Stackless which provides the Stackless green threads functionality as an extension module. Is there any benefit from using "native" Stackless from PyPy than PyPy + greenlet + some dispatcher (eg: gevent )? Or the problem is that i can't use those

Stackless in PyPy and PyPy + greenlet - differences

牧云@^-^@ 提交于 2019-12-31 10:41:12
问题 New version of PyPy ships with integrated Stackless . As far as I know the bundled Stackless is not the same as the origin Stackless from 2001 with continuations. So mainly it is the green threads framework with dispatcher. Greenlet is a spin-of Stackless which provides the Stackless green threads functionality as an extension module. Is there any benefit from using "native" Stackless from PyPy than PyPy + greenlet + some dispatcher (eg: gevent )? Or the problem is that i can't use those

Which programming languages support hot code swapping and/or sandboxing?

*爱你&永不变心* 提交于 2019-12-20 12:46:10
问题 I would like to write a web based MMO game that will allow users to write AI and run it as part of the game. I plan to use Html5 for graphics and want this to be web based so it can be accessed from smartphones. I need to find a programming language that will support sandboxing, concurrency, hot code swapping, and a large library to make things easier. At this time my research is turning up Erlang, Stackless Python, and Lua. Any help is appreciated. 回答1: Erlang does not support sandboxing, so

Stackless python and multicores?

房东的猫 提交于 2019-12-18 10:54:09
问题 So, I'm toying around with Stackless Python and a question popped up in my head, maybe this is "assumed" or "common" knowledge, but I couldn't find it actually written anywhere on the stackless site. Does Stackless Python take advantage of multicore CPUs? In normal Python you have the GIL being constantly present and to make (true) use of multiple cores you need to use several processes, is this true for Stackless also? 回答1: Stackless python does not make use of any kind of multi-core

What challenges promote the use of parallel/concurrent architectures?

倖福魔咒の 提交于 2019-12-05 01:51:18
问题 I am quite excited by the possibility of using languages which have parallelism / concurrency built in, such as stackless python and erlang, and have a firm belief that we'll all have to move in that direction before too long - or will want to because it will be a good/easy way to get to scalability and performance. However, I am so used to thinking about solutions in a linear/serial/OOP/functional way that I am struggling to cast any of my domain problems in a way that merits using

Which Actor model library/framework for python and Erlang-like? [closed]

帅比萌擦擦* 提交于 2019-12-03 03:03:05
问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 2 months ago . I am looking for an easy-to-learn Actor library or framework for Python 2.x. I have tried Candygram and Twisted but I did not like them. I'd like something that will be easy to extend to suppero Greenlet (= stackless python). Candygram is too old. Twisted is too complicated. Gevent: it is unclear if it can

Python/Erlang: What's the difference between Twisted, Stackless, Greenlet, Eventlet, Coroutines? Are they similar to Erlang processes?

余生长醉 提交于 2019-12-03 00:33:39
问题 My incomplete understanding is that Twisted, Stackless, Greenlet, Eventlet, Coroutines all make use of async network IO and userland threads that are very lightweight and quick to switch. But I'm not sure what are the differences between them. Also they sound very similar to Erlang processes. Are they pretty much the same thing? Anyone who could help me understand this topic more would be greatly appreciated. 回答1: First of all, non-blocking I/O has nothing in common with green threads or

Python/Erlang: What's the difference between Twisted, Stackless, Greenlet, Eventlet, Coroutines? Are they similar to Erlang processes?

拜拜、爱过 提交于 2019-12-02 14:08:34
My incomplete understanding is that Twisted, Stackless, Greenlet, Eventlet, Coroutines all make use of async network IO and userland threads that are very lightweight and quick to switch. But I'm not sure what are the differences between them. Also they sound very similar to Erlang processes. Are they pretty much the same thing? Anyone who could help me understand this topic more would be greatly appreciated. andreypopp First of all, non-blocking I/O has nothing in common with green threads or coroutines, but it can affect how they're scheduled. Now: Twisted is a classic non-blocking I/O