Для чего я использовал бы Stackless Python?

Основным преимуществом Stackless Python является поддержка очень легких сопрограмм. CPython не поддерживает сопрограммы изначально (хотя я ожидаю, что кто-то опубликует в комментариях хакерский метод на основе генератора), поэтому Stackless - явное улучшение CPython, когда у вас есть проблема, которая выигрывает от сопрограмм.

Я думаю, что основная область, в которой они преуспевают, - это когда у вас много одновременных задач, выполняемых в вашей программе. Примерами могут быть игровые объекты, которые запускают сценарий цикла для своего ИИ, или веб-сервер, который обслуживает множество клиентов со страницами, которые создаются медленно.

Тем не менее, у вас все еще есть много типичных проблем с корректностью параллелизма в отношении общих данных, но детерминированное переключение задач упрощает написание безопасного кода, поскольку вы точно знаете, куда будет передано управление, и, следовательно, знаете точные точки, в которые состояние должно быть актуальным.

EVEOnline в основном запрограммирован на Stackless Python. У них есть несколько блогов разработчиков по его использованию. Кажется, это очень полезно для высокопроизводительных вычислений.

Я твердо подозреваю, что быстрее , чем , и не требует распределения. Так что если x редко когда бар, то первый фрагмент хорошо. Если x в основном Bar, то рекомендуется использовать как , так как не требуется второго литья. Это зависит от использования и обстоятельств кода.

Что сказал Дассуки. Получите GDAL от http://www.kyngchaos.com/software: Рамки . Используйте его для преобразования файла формы в GeoJSON так:

$ ogr2ogr -f "GeoJSON" output.json input.shp

eg

$ ogr2ogr -f "GeoJSON" /tmp/world.json world_borders.shp world_borders
$ cat /tmp/world.json
{
"type": "FeatureCollection",
"features": [
{ "type": "Feature", "properties": { "CAT": 1.000000, "FIPS_CNTRY": "AA",
  "CNTRY_NAME": "Aruba", "AREA": 193.000000, "POP_CNTRY": 71218.000000 }, 
  "geometry": { "type": "Polygon", "coordinates": [ [ [ -69.882233, ...
  ...

Тирлер уже упоминал, что в Eve Online использовался stackless. Имейте в виду, что

(..) без стека добавляет к этому еще один поворот, позволяя разделять задачи на более мелкие задачи, Tasklets, которые затем можно разделить от основной программы для выполнения самостоятельно. Это может использоваться для задач «пожар и забвение», таких как отправка электронной почты или отправка события, или для операций ввода-вывода, например, отправка и получение сетевых пакетов. Одна задача ожидает пакет из сети, в то время как другие продолжают запускать игровой цикл.

Он в некотором пути похож на потоки, но не является упреждающим и явно запланирован, поэтому при синхронизации возникает меньше проблем. Кроме того, переключение между задачами происходит гораздо быстрее, чем переключение потоков, и вы можете иметь огромное количество активных задач, в то время как количество потоков сильно ограничено компьютерным оборудованием.

(получил это цитирование от здесь )

На PyCon 2009 был дан очень интересный разговор , описывающий, почему и как Stackless используется на CCP Games.

Кроме того, имеется очень хороший вводный материал , в котором описывается, почему безстейкинг является хорошим решением для Ваших приложений. (она может быть несколько старой, но я думаю, что стоит прочитать).

Основная полезность зеленых потоков, на мой взгляд, заключается в реализации системы, в которой имеется большое количество объектов, выполняющих операции с высокой задержкой. . Конкретным примером может быть взаимодействие с другими машинами:

def Run():
    # Do stuff
    request_information() # This call might block
    # Proceed doing more stuff

Потоки позволяют писать приведенный выше код естественным образом, но если количество объектов достаточно велико, потоки просто не могут работать должным образом. Но вы можете использовать зеленые нити даже в очень больших количествах. request_information () выше может переключиться на какой-то планировщик, где другая работа ожидает, и вернуться позже.Вы получаете все преимущества возможности вызывать «блокирующие» функции , как если бы они возвращались немедленно без использования потоков.

Очевидно, что это очень полезно для любого вида распределенных вычислений, если вы хотите писать код простым способом.

Также интересно, что несколько ядер уменьшают ожидание блокировок:

def Run():
    # Do some calculations
    green_lock(the_foo)
    # Do some more calculations

Функция green_lock в основном пытается получить блокировку и просто переключается на основной планировщик, если он выходит из строя из-за других ядер. используя объект.

И снова зеленые потоки используются для смягчения блокировки, позволяя писать естественный код и при этом работать хорошо.

Хотя я не использовал сам Stackless, я использовал Greenlet для реализации высококонкурентных сетевых приложений. В Linden Lab его использовали для следующих целей: высокопроизводительные интеллектуальные прокси, быстрая система для распределения команд по огромному количеству машин, приложение, выполняющее множество операций записи и чтения баз данных (в соотношении примерно 1:2, что является очень интенсивной записью, поэтому большую часть времени оно проводит в ожидании возврата базы данных), а также приложение типа web-crawler для внутренних веб-данных. В принципе, любое приложение, которое ожидает, что ему придется выполнять много сетевых операций ввода-вывода, выиграет от возможности создать миллиард легких потоков. 10 000 подключенных клиентов не кажутся мне огромной проблемой. Однако

Stackless или Greenlet не являются полноценным решением. Они очень низкоуровневые, и вам придется проделать много обезьяньей работы, чтобы создать приложение, использующее их по максимуму. Я знаю это, потому что я поддерживаю библиотеку, которая обеспечивает сетевой и планирующий слой поверх Greenlet, в частности потому, что с ней писать приложения намного проще. Сейчас таких библиотек много; я поддерживаю Eventlet, но также есть Concurrence, Chiral и, возможно, еще несколько, о которых я не знаю.

Если приложение, которое вы хотите написать, похоже на то, о котором я писал, рассмотрите одну из этих библиотек. Выбор между Stackless и Greenlet несколько менее важен, чем решение о том, какая библиотека лучше всего подходит для того, что вы хотите сделать.