Комментарии 19
Это всё понятно, асинхронность и на бейсике можно сделать. Сложность, как мне кажется, в реализации долгоживущего php-процесса. Изначально php был спроектирован под короткий запрос-ответ, эта парадигма позволила отказаться от сложного gc. Теперь же процессы могут работать минимум днями, насколько они подвержены утечкам памяти?
Не думаю что в ядре пхп есть утечки памяти. Наверное это фиксится. Тут больше вопрос удобства работы, количества либ и фреймворков. Пхп только становится на этот путь, тогда как у других тема неблокиоубщиего ввода вывода была из коробки, к примеру как у дарт или ноджс
Так это тоже не проблема языка. Все те же самые утечки памяти могут быть и на ноде. В long-running процессах управление памятью полностью ложится на плечи разработчика.
Сильное утверждение про long-running процессы и управление памятью, есть мнение что в Java как-то этот вопрос решается без полного прямого управления памятью
так и тут не надо.
сам по себе php в принципе уже давно не течет, вопрос в том не создатите ли вы сами утечки памяти (или фреймворк, который вы используете).
если в java каждый запрос сохранять в памяти и никогда не очищать, то память закончится — тех же самых правил следует придерживаться и в php.
а писать вручную unsetы не нужно (если, конечно, у вас там не какой-то частный случай).
И потом видим OutOfMemoryException в логах )
Если есть GC — это еще не значит что нельзя вызвать утечки.
Точнее «утечки» были — когда я сохранял ссылки на объекты которые были не нужны уже. Начал удалять ссылки — утечки пропали.
Сейчас стало ещё лучше всё в этом плане.
github.com/gotzmann/comet
Вот ничего нового для себя не прочёл.
Но послевкусие от статьи сложное.
Тяжёлый язык для достаточно простой вещи.
То ли текст недостаточно стрктурирован. То ли ещё что-то…
Но тяжело читать было.
Ну и заголовок слегка запутал.
А чем плох вариант просто пробросить системный вызов epoll в линуксе? Linux уже предоставляет возможности асинхронного io виде синхронного вызова epoll_wait в бесконечном цикле. Вот я нашел такую библиотеку (https://github.com/chopins/php-epoll), какие есть недостатки у такого подхода ?
for (;;) {
$nfds = $epoll->wait($events, MAX_EVENTS, -1);
if ($nfds == -1) {
perror("epoll_wait");
exit(EXIT_FAILURE);
}
for ($n = 0; $n < $nfds; ++$n) {
if ($events[$n]->data->fd == $listen_sock) {
$conn_sock = stream_socket_accept($stream);
if (!$conn_sock) {
perror("accept");
exit(EXIT_FAILURE);
}
stream_set_blocking($conn_sock, false);
$ev->setEvent(Epoll::EPOLLIN | Epoll::EPOLLET);
$connFdno = $epoll->getFdno($conn_sock, Epoll::RES_TYPE_NET);
$ev->setData(['fd' => $connFdno]);
if ($epoll->ctl(Epoll::EPOLL_CTL_ADD, $connFdno,
$ev) == -1) {
perror("epoll_ctl: conn_sock");
exit(EXIT_FAILURE);
}
} else {
do_use_fd($events[$n]->data->fd);
}
}
}Понятно что это только работа с голым tcp но ведь можно подключить какую-нибудь библиотеку которая будет парсить из tcp-потока http-запросы и таким образом получим на php асинхронный http-сервер который будет не хуже чем в NodeJS (и также это избавляет от необходимости использовать Apache или Nginx перед php)
Вот и ffi подъехал, думаю пройдёт ещё время и все взлетит, как по мне велосипедостроение у пхпшников в крови)
Подумайте как может быть устроен API подобной библиотеки для парсинга http-запросов. И сравните с уже существующим React\Http\Server.
а чем плох вариант просто вызывать в цикле функцию вроде parseNextHttpRequest(buf) с передачей буфера и получением словаря http-хедеров и значений (а также статуса и тела). Вполне себе органично вписывается в тот пример кода выше где вместо вызова do_use_fd(..) будет вызов parseNextHttpRequest а потом уже обработка самого http-запроса вызовом еще одной функции
Все асинхронные вещи пишем на NodeJS.
многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный"
Покажите мне этих многих. Обычно вижу только нытье забивающих гвозди микроскопом или делающих троллейбус из булки хлеба.
Мифы об асинхронном PHP: он не по-настоящему асинхронный