>>>[оверквотинг удален]
>> Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.
> Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется
> она через FSM'ы и select/poll/etc, или через движки типа eventlib.В некотором смысле, можно сказать и так. Но вы пробовали когда-нибудь писать используя thread_create? Одно дело писать программу в ивентуальном стиле, и совсем другое в чисто итеративном. В первом случае, без создания конечного автомата далеко не уедешь. Во втором же, всё как-то само по себе выходит.
Мы отклоняемся от темы. Говоря слова "многозадачность" мы всё же имеем в виду потоки выполнения, а не тысячи инстансов конечных автоматов разбирающих HTTP в apache, не так ли? Или это надо было отдельно оговорить?
> Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не
> общего подхода.
Нет, не думаю. У меня есть другое объяснение тому. Если потоков немного, то пенальти по производительности от kernel-space потоков, как правило невелики (хотя, конечно, бывают и яркие обратные примеры). А если потоков много, то как правило, приходится ориентироваться на многие тысячи файловых дескрипторов, а когда так, придётся мешать в одну кучу libpthread и libpth. А это мало того, что требует внимательности (писать ли pth_create или pthread_create?), так ведь каждый user-space поток, всё же, придётся писать с оглядкой на реентерабельность. В частности, придётся пользоваться реализацией примитивов синхронизации из libpthread, а не из libpth. То есть часть существенных преимуществ относящихся к простоте кода и его эффективности уже будет утеряна. Из плюсов подхода останется лишь итеративность кода, и возможность прозрачно организовать lazy aio. Стоит ли это лишнего депенданса -- ещё большой вопрос. Тем более, что привычный ивентуальный подход хорошо известен, проверен временем и десятком(-ами?) успешных известных примеров.
> Ну, во-первых, кооперативная, а не корпоративная:)
Точно-точно. =)
> Во-вторых, к чему Вы это?
> Хотите полноценную вытесняющую многозадачность в Python?
Нет, я не хочу. На python я давно забил. Собственно, никогда им особо и не интересовался. Скучный безликий язык. Если уж и разглядывать что-нибудь из языков этого класса, так ruby, по-моему, существенно приятнее. Как в плане синтаксических плюшек, так и в плане семантических.
> Модуль multiprocessing находится
> в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые
> переменные и возможность делать менеджеры доступа с персональной политикой синхронизации.
М-м-м... Но это же на самом деле полноценные тяжеленные процессы, так? Со своим адресным пространством. Значит надо возится с SHM, только для того, чтобы передать картинку? Вариант, конечно. Но, допустим, если мы попытаемся реализовать апач на python'e -- не знаю зачем, но допустим, -- как мы сможем создать три процесса, по двадцать пять kernel-space потоков в каждом процессе, так чтобы каждый поток по сотне файловых дескрипторов обрабатывал в параллели?
>> А вы не сталкивались с такой фишкой, как опциональная типизация переменных? То
>> есть когда язык позволяет создать как типизированную переменную, так и не
>> типизированную. Помимо удобств отладки (рантайм исключения, при попытки записать int в
>> переменную типа string), возникает офигенный простор для оптимизации, путём выпиливания
>> из бутылочных горлышек тормозов порождённых динамической типизацией.
> Ага, для этого давно уже есть Cython.
И как это чудо прикрутить к скриптам, которые мне иногда приходится писать в LibreOffice?
Cython -- это же уже не питон. Он уже язык с обязательной компиляцией. С другим синтаксисом. Дополнительными депендансами. Поэтому те python'овские скрипты, которые я использую в системе, так всегда и останутся питоновскими, и никогда не будут использовать статическую типизацию, даже если разработчики поймут, что в некоторых ситуациях это удобно и полезно.
>> Python неплохой язык, для простеньких задач. Но он начался с идеологии, и
>> до сих пор не может отказаться от этой идеологии "всё можно
>> сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические
>> задачи, которые предъявляют вполне определённые требования к языку. Когда же язык,
>> вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить
>> что требования некошерны... Это как минимум странно.
> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
> решается. Просто надо знать чуть шире, чем одно базовое средство.
Я бы поверил Вам на слово. Если бы речь шла не о Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя Perl'у. Это фатально на нём сказалось. То есть он достаточно приятный язык, допустим PHP в разы хуже и неудобнее. Но и всё же, он далёк от идеала. По-крайней мере существенно дальше, чем ruby.
