>>> Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.
>> Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется
>> она через FSM'ы и select/poll/etc, или через движки типа eventlib.
> В некотором смысле, можно сказать и так. Но вы пробовали когда-нибудь писать
> используя thread_create?Именно эту библиотеку - нет, а вообще - да.
Ничего принципиально проблемного не увидел. Более того, возможность строить прямой код вместо FSM оказалась сильно удобнее во многих случаях (хотя и не идеальным вариантом).
> Одно дело писать программу в ивентуальном стиле, и совсем
> другое в чисто итеративном. В первом случае, без создания конечного автомата
> далеко не уедешь.
Но при этом совершенно не обязательно рисовать тот автомат явно.
> Мы отклоняемся от темы. Говоря слова "многозадачность" мы всё же имеем в
> виду потоки выполнения, а не тысячи инстансов конечных автоматов разбирающих HTTP
> в apache, не так ли? Или это надо было отдельно оговорить?
Видимо, надо было отдельно. Впрочем, уже понятно.
Если мы отклоняемся от темы, то лучше было бы говорить немного о другом - а именно, почему вообще подход через кооперативные задачи (они же green threads, они же fibers) лучше для теории (и хуже для практики, потому что мало используется).
>> Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не
>> общего подхода.
> Нет, не думаю. У меня есть другое объяснение тому. Если потоков немного,
> то пенальти по производительности от kernel-space потоков, как правило невелики (хотя,
> конечно, бывают и яркие обратные примеры). А если потоков много, то
> как правило, приходится ориентироваться на многие тысячи файловых дескрипторов, а когда
> так, придётся мешать в одну кучу libpthread и libpth.
А смешение в одну кучу pthreads и FSM, как сделано в самых высокопроизводительных системах, Вас не пугает? Там ровно те же проблемы.
> А это
> мало того, что требует внимательности (писать ли pth_create или pthread_create?), так
> ведь каждый user-space поток, всё же, придётся писать с оглядкой на
> реентерабельность. В частности, придётся пользоваться реализацией примитивов синхронизации
> из libpthread, а не из libpth.
И что это меняет (по сравнению с бутербродом pthreads+FSM, потому что имеет сравнивать только с ним)? На практике достаточно, чтобы синхронизация pthreads была "внутри" синхронизации pth, и это решает, насколько я понимаю, все проблемы, которые тут решаются. Те же, которые не решаются, точно так же не решаются и в случае FSM внутри pthread, и тогда требуется явные меры синхронизации со стороны программиста (но таких случаев лучше избегать).
Насколько я понимаю, это аргументы в ту же сторону, куда и Вы клоните? Но тогда что от этого меняется?
> То есть часть существенных преимуществ
> относящихся к простоте кода и его эффективности уже будет утеряна. Из
> плюсов подхода останется лишь итеративность кода, и возможность прозрачно организовать
> lazy aio. Стоит ли это лишнего депенданса -- ещё большой вопрос.
> Тем более, что привычный ивентуальный подход хорошо известен, проверен временем и
> десятком(-ами?) успешных известных примеров.
То есть Вам по факту пофиг, будут green threads или один движок событий. Тогда при чём тут Питон?
>> Во-вторых, к чему Вы это?
>> Хотите полноценную вытесняющую многозадачность в Python?
> Нет, я не хочу. На python я давно забил. Собственно, никогда им
> особо и не интересовался. Скучный безликий язык. Если уж и разглядывать
> что-нибудь из языков этого класса, так ruby, по-моему, существенно приятнее. Как
> в плане синтаксических плюшек, так и в плане семантических.
Ну кому "скучный и безликий", а кому отличная рабочая лошадка, при этом приятная и удобная. В отличие от Ruby, который требует выворота мозгов, который не окупается.
>> Модуль multiprocessing находится
>> в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые
>> переменные и возможность делать менеджеры доступа с персональной политикой синхронизации.
> М-м-м... Но это же на самом деле полноценные тяжеленные процессы, так? Со
> своим адресным пространством. Значит надо возится с SHM, только для того,
> чтобы передать картинку? Вариант, конечно.
А чем это отличается от передачи данных между тредами? Там такое же SHM и та же синхронизация. Только в случае тредов вся память зашарена насильно, а в случае процессов это надо делать явно.
(Нет, я, конечно, знаю, где отличия. Но для обычной питоновой роли они малосущественны.)
> Но, допустим, если мы попытаемся реализовать
> апач на python'e -- не знаю зачем, но допустим, -- как
> мы сможем создать три процесса, по двадцать пять kernel-space потоков в
> каждом процессе, так чтобы каждый поток по сотне файловых дескрипторов обрабатывал
> в параллели?
Странный запрос. Очень странный.
Если уж говорить об апаче, то у него общего между тредами или процессами (в зависимости от MPM) минимум. После перечитывания конфига они расползаются и всё взаимодействие - это запись в лог и борьба за очередь на сокет.
И в этом случае пофиг, на сколько каких сущностей оно расцеплено, лишь бы не мешало друг другу.
Ваша постановка задачи в виде "три процесса по 25 kernel-space потоков" уже намеренно натянута, как те "тендеры", которые рассчитаны ровно на одного производителя и одного поставщика.
> И как это чудо прикрутить к скриптам, которые мне иногда приходится писать
> в LibreOffice?
> Cython -- это же уже не питон. Он уже язык с обязательной
> компиляцией. С другим синтаксисом. Дополнительными депендансами. Поэтому те python'овские
> скрипты, которые я использую в системе, так всегда и останутся питоновскими,
> и никогда не будут использовать статическую типизацию, даже если разработчики поймут,
> что в некоторых ситуациях это удобно и полезно.
Если для них не критична скорость - так пусть остаются. В чём проблема-то?
Я плохо представляю себе, честно говоря, необходимость, например, высокой математики в libreoffice.
>> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
>> решается. Просто надо знать чуть шире, чем одно базовое средство.
> Я бы поверил Вам на слово. Если бы речь шла не о
> Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя
> Perl'у. Это фатально на нём сказалось.
Простите, я не понимаю, откуда у Вас такие выводы. С Perl они стартовали (как самостоятельные языки) ноздря в ноздрю, но развивались совершенно без оглядки друг на друга где-то до середины 90-х. Далее, противопоставление по каким свойствам? Я не вижу ни одного примера того, что было бы намеренно сделано "не как в Perl" и при этом объективно бы ухудшило потребительские свойства языка. Наоборот, практически все принципиальные решения в Python привели к лучшему результату. Например, я таким считаю возможность писать a.b.c вместо $a->{b}{c}, даже такие банальности синтаксиса уже улучшают читабельность в разы. Или отсутствие принципиально разных подходов для написания одноэкранников и большого кода. Или лучшая ориентация на генерацию исключений вместо отдачи undef или аналога, маскирующего проблему.
И, кстати, при чём тут однобокая развитость к вопросу о наличии Cython? Что, для Perl есть вариант написания со статической типизацией, компилируемый в эффективный машинный код?
> То есть он достаточно приятный
> язык, допустим PHP в разы хуже и неудобнее. Но и всё
> же, он далёк от идеала.
> По-крайней мере существенно дальше, чем ruby.
Для Вас Ruby близок к идеалу? Извините, но jIMHO Ruby это достаточно однобокая поделка на тему "мы тут попытались сделать функциональную ориентированность через <strike>задницу соседа</strike> объектную ориентированность, причём записать это всё по-японски, чтобы круче выглядело".
