Python tasklet 不是打破了无"GOTO"规则吗？

Question

我对Stackless Python的tasklets进行了大量的谷歌研究。每个来源都将其作为线程提及

stackless.com：微线程：tasklet包装函数，允许它们作为微线程启动。

disinterest.orgv： Tasklets — 轻量级线程

但小任务并不一致。它们逐个执行代码的一部分。

像这样编写代码：

def function(n):
   print n
   print n
   stackless.schedule()
stackless.tasklet(function)(3)
stackless.tasklet(function)(10)
stackless.run()

将打印

3
3
10
10

tasklet 执行代码，直到遇到 stackless.schedule（），然后它从开始或从最后一个暂停的位置执行下一个 tasklet。

每个程序员都知道"没有GOTO"的黄金法则。我的问题是：

这与GOTO有何不同？
如果不并行执行 tasklet，使用它们有什么好处？
如果它们不是真正的线程，为什么每个来源都将它们作为线程替代品？

Answer 1

它与goto有什么不同？

这与goto的不同之处在于，您没有指定要去的地方。通过交出你的任务（打电话stackless.schedule()），你说的只是"我现在完成了;您可以稍后回复我"，而不是"从文件 X 的第 n 行开始执行"。"goto 不好"的建议源于这样一个事实，即它允许您编写意大利面条代码，其中程序的执行是不可能遵循的。另一方面，Tasklet（或协程）在这方面要好得多，因为您知道每个 tasklet 都会运行完成。

如果不并行执行 tasklet，使用它们有什么好处？

并发性不同于并行性。并行性是指两个任务实际上同时运行。并发是指两个任务在执行过程中可以重叠，但它们不一定在同一时刻运行。任务是并发的，但不是并行的。小任务的优点基本上是并发性。

如果它们不是真正的线程，为什么每个来源都将它们作为线程替代品？

如果您可以放弃并行性，则它们是线程替代方案，以获得较低的开销。它们仍然是线程，因为它们仍然允许多个并发执行路径，即使它们不是严格并行的。

Answer 2

我看不出这与 goto 想象以下内容有什么相似之处。

def Eat():
   while True:
        do_something()
        stackless.schedule()
def Play():
   while True:
        do_another_thing()
        stackless.schedule()
def Sleep():
    while True:
        do_something_else()
        stackless.schedule()
stackless.tasklet(Eat)()
stackless.tasklet(Play)()
stackless.tasklet(Sleep)()

它本质上是单核线程，每个线程都可以决定何时将控制权交给另一个等待任务

它与实时操作系统如何实现任务调度非常相似