Мультитредовость в PHP

[kode]

Мультитредовость в PHP

Возможно это прозвучит глупо, но что мешает реализовать экстеншен к ядру?

Возможно я чего-то непонимаю, но вроде логично же. Сначала регистрируем функцию-колбек (как в CreateThread()), потом main'е (или сразу после, а можно и в отдельном треде ) запускаем бесконечный цикл, в котором дёргаём функ-цию экстеншена, который будет:

1) загружать контекст уникальный для выполняемого колбека
2) выполнять один опкод из кода колбека
3) дампить контекст (обьявленные переменные)
4) переходим к следующему контексту и на пункт 1

ЗЫ. Извините, поток сознания, время 8 утра
ЗЫЫ. Это моё представление о реализации многозадачности/многонитевости в ОС.
ЗЫЫЫ. И я знаю что не всё так просто....

 

[phprus]

kode
Уже была попытка реализовать потоки в php, но почему-то эта идея не получила признания и уже 5 лет не развивается.
Вот этот модуль: http://pecl.php.net/package/threads

запускаем бесконечный цикл, в котором дёргаём функ-цию экстеншена, который будет:

Алгоритм планирования, который вы описали очень не эффективен. Гораздо лучше создавать потоки средствами ОС (например pthread) и оставлять планирование на совесть системы. Мне кажется ОС с этой задачей справится гораздо лучше.

 

[FractalizeR]

Интересно, для какого рода задач может понадобиться использовать треды в PHP?

 

[phprus]

FractalizeR
Ну в Perl'е же они есть.

Да и не только для веба на php пишут.

 

[FractalizeR]

Согласен Странно тогда, что разработка расширения заглохла.

P.S. никак не могу себя заставить сесть за Perl, посмотреть, что за чудище такое и почему его Write-Only Language называют

 

[tony2001]

>Возможно это прозвучит глупо, но что мешает реализовать экстеншен к ядру?

На то есть две основных причины:

1) это не имеет никакого смысла.
если ты знаешь что такое потоки и умеешь их использовать, то и пиши на C/C++, зачем тебе враппер вокруг С?

2) PHP зависит от великого множества библиотек и работает на многочисленных ОС.
многие из этих библиотек никогда не поддерживали многопоточность (а если и поддерживают, то очень плохо).
более того, есть даже системные функции, которые не поддерживают потоки.
поэтому, поскольку мы никак не можем гарантировать стабильность всей комбинации, нечего и пытаться.

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

 

[fixxxer]

>почему его Write-Only Language называют

http://www.linux.org.ru/view-message.jsp?msgid=392747

НЕ ЗАПУСКАТЬ!

 

[phprus]

tony2001

1) это не имеет никакого смысла.
если ты знаешь что такое потоки и умеешь их использовать, то и пиши на C/C++, зачем тебе враппер вокруг С?

А зачем тогда нужен PHP который по сути есть враппер вокруг машинных кодов? Скорость разработки на PHP даже многопоточной программы будет выше чем на С, особенно если эта программа работает с текстами.

А вот со второй и третьей причинами я согласен.

 

[Андрейка]

phprus
а зачем нужна многопоточная программа на пхп.. особенно для работы с текстами?

 

[tony2001]

>А зачем тогда нужен PHP который по сути есть враппер вокруг машинных кодов?

большинство не знает машинных кодов.
большинство не знает и не понимает потоков.

>Скорость разработки на PHP даже многопоточной программы будет выше чем
>на С, особенно если эта программа работает с текстами.

у меня не получилось найти какой-либо смысл в этом предложении.

 

[phprus]

Андрейка

а зачем нужна многопоточная программа на пхп.. особенно для работы с текстами?

Убедили. Я не смог найти аргументов чтобы ответить на этот вопрос (

 

[nerezus]

1) это не имеет никакого смысла.
если ты знаешь что такое потоки и умеешь их использовать, то и пиши на C/C++, зачем тебе враппер вокруг С?

Я думаю, что как минимум 80% сознательного населения этого форума это знают. Но они все же посещают форум по пхп. А не по С. Значит им нужен пхп. Логично?

поэтому, поскольку мы никак не можем гарантировать стабильность всей комбинации, нечего и пытаться.

А в чем проблема? В других языках то отлично работает. Взять хотя бы питон, к примеру.

 

[tony2001]

>Я думаю, что как минимум 80% сознательного населения этого форума это знают.

Ха-ха.
80% населения форума не могут правильно написать слово "правильно", вы про многопоточность говорите.

>Но они все же посещают форум по пхп. А не по С. Значит им нужен пхп. Логично?

"Я знаю C, значит PHP нужна многопоточность".
Никакой логики в этом нет.

>А в чем проблема? В других языках то отлично работает. Взять хотя бы питон, к примеру.

Ну вот и используйте Питон.
А в языку, который 99.999999% времени работает под веб-серверами, многопоточность в принципе ни к чему.

 

[kode]

2) PHP зависит от великого множества библиотек и работает на многочисленных ОС.
многие из этих библиотек никогда не поддерживали многопоточность (а если и поддерживают, то очень плохо).
более того, есть даже системные функции, которые не поддерживают потоки.
поэтому, поскольку мы никак не можем гарантировать стабильность всей комбинации, нечего и пытаться.

Дык, если есть проблемы с библиотеками, то что мешает реализовать это собственными силами, те средствами виртмашины.

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

Zend Extension? дебагеры же пишут, но чесное слово я в деле внутренностей PHP дилетант

 

[tony2001]

>Дык, если есть проблемы с библиотеками, то что мешает реализовать это
>собственными силами, те средствами виртмашины.

реализовать что? библиотеки? своими силами?
очевидно, отсутствие этих самых сил.
и смысла.

>Zend Extension? дебагеры же пишут, но чесное слово я в деле внутренностей PHP дилетант

ну тогда просто верь мне на слово.

 

[TutanXamoN]

Пардон что вклиниваюсь в данное обсуждение но могли бы Вы мне привести пример задачи реализация которой при условии многопоточности php не имела бы аналогов(выигрывающих либо вообще) в скорости_работы/выполняемой_работе/удовлетворении_поставленных_требований хотя бы теоретически?

 

[kode]

Автор оригинала: TutanXamoN
Пардон что вклиниваюсь в данное обсуждение но могли бы Вы мне привести пример задачи реализация которой при условии многопоточности php не имела бы аналогов(выигрывающих либо вообще) в скорости_работы/выполняемой_работе/удовлетворении_поставленных_требований хотя бы теоретически?

Есть утилиты, для написания которых я пользуюсь PHP (Например утилита которая коннектится к DC хабу, скачивает файл листы всех пользователей и складывает их в определённую папку, а потом индексатор (тоже написанный на PHP) пробегается по файллистам и забивает файлы из них в БД. Если бы я писал бы это на Cи - то мне пришлось: потратить гораздо больше времени на написание, потратить время на изучение библиотек (libxml например), долго дебажить всё это)

http://code.airnet.ru/sandbox/dcview/

Частенько приходится пользоватся самопальными решениями типа поллеров, но имхо криво это

Например:

$client = new ClientClass('localhost');
$terminal = new Terminal(PHP_STDIN, PHP_STDOUT);

Poller::register($client);
Poller::register($terminal);

/* do stuff */

do{
$exit = Poller::poll();
}while(!$exit);

 

[TutanXamoN]

Есть утилиты, для написания которых я пользуюсь PHP (Например утилита которая коннектится к DC хабу, скачивает файл листы всех пользователей и складывает их в определённую папку, а потом индексатор (тоже написанный на PHP) пробегается по файллистам и забивает файлы из них в БД. Если бы я писал бы это на Cи - то мне пришлось: потратить гораздо больше времени на написание, потратить время на изучение библиотек (libxml например), долго дебажить всё это)

Ну скажем так :
1. Не вижу ответа на мой вопрос ни в Вашем посте ни в Вашем коде ни в поставленной задаче.
2. На Вашем же примере становится очевидна ситуация - програмисты пишут на том языке который они знают вне зависимости от гибкости полученного решения его скорости работы и чёткого понимания зачем он пишет ето на етом языке.
3. То что у нас называют гибкостью синтаксиса - как правило попытка "есть суп бампером" (с) БОР , зная о существовании "ложки". Часто всё делаеться "бампером" оправдываясь в данной ситуации тем что я не владею "ложкой" а учить её долго.

 

[kode]

Автор оригинала: TutanXamoN
2. На Вашем же примере становится очевидна ситуация - програмисты пишут на том языке который они знают вне зависимости от гибкости полученного решения его скорости работы и чёткого понимания зачем он пишет ето на етом языке.

Соглашусь что надо писать на том языке который для этого предназначен, но существуют решения (quick & dirty) в которых быстрота написания превыше всего. Мне важно было закатать все файл листы в БД при минимальных трудо/время затратах....а не создавать гибкое и производительно решение, тут уже вопрос предпочтений....

PS. Moderators, move this thread to offtopic, please....

 

[TutanXamoN]

Соглашусь что надо писать на том языке который для этого предназначен, но существуют решения (quick & dirty) в которых быстрота написания превыше всего. Мне важно было закатать все файл листы в БД при минимальных трудо/время затратах....а не создавать гибкое и производительно решение, тут уже вопрос предпочтений....

Да увы понятие "(quick & dirty)" у нас сейчас в почёте ибо сначала нужно быстро а потом "зачем переделывать если и так работает". (не подумайте что я идеален - сам таким занимаюсь, но в обсуждении нужно быть объективным, пусть и субъективно)

PS. Moderators, move this thread to offtopic, please....

+1