-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Как работают потоки.
- Автор темы Redjik
- Дата начала
serglt
Анус, ой, Ахтунг
Вебсервера бывают разные, однапроцесные (неблокируемые соединения), многопроцесные (форк основного процесса на каждое соединение), нитевые (threads).
Каждый сеанс для каждого клиента индивидуальный. Как в прочем и для других КС (не только веб) приложений.
1. Клиент через форму запостил файл на сервер, веб сервер его кладет в папку tmp или другую,
ему по сути по барабану кто обрабатывает получение файла, пхп, перл или другое цги.
Все это происходит именно в веб сервере. Можно файл запостить хоть в обычный хтмл файл, в темп папке он появится, и также, как темповый удалится.
Только при полном получении HTTP запроса от клиента (браузера) происходит обработка запроса и передача его в цги,
в который уже передается результаты веб сервера по загрузке файла и прочему. По другому быть не может, передаваемый файл - как и куки это всего лишь запрос.
Как можно запустить обработку запроса не получив оного с полу кукой или полу файлом к примеру? Есть передачи запроса пачкованием, но сути не меняет, пачки склеиваются в веб сервере. а потом обрабатываются уже настроенным ЦГИ
2. Неужели поменялась политика браузеров? Что, уже можно тырить файлы с клиента при помощи xmlhttprequest? Как вы файл то им отдадите данной технологией?
3. При fopen - это дескриптор, указывающий на начало файла и текущее смещение при чтении или записи.
Файл не грузится в память полностью, ты можешь его читать по байту (символьно) или пачками (строками) соотв. получаешь свое кол - во байт в приложении (скрипте),
условно память выделяется тока под твое кол - во байт.
4. Сокеты, в сис вызовах - это тот же файловый дескриптор.
Клиент получает от сервера данные, сервер к примеру отслылает 100 байт, клиент смог получить тока 30 из за тормознутости сети,
клиент серверу об этом говорит, получил 30. Сервер отправляет повторно сместившись на 30 байт.
Если ни тот не другой ничего не получают, тоесть висят, они могут висеть вечно, или пока кто нить не отвалится.
5. Базы данных и подобные (ftp, ssh, pop, imap, smtp и т. д.), это то же сокет соединение, со своими командами, и разными состояниями/командами/ответами
При выборке - БД формирует результат, и он хранится на стороне сервера а не в клиенте (в данном случае, клиент - PHP).
База так же отдает запись (по команде fetch_*) и смещается на след запись как и в файле,
тока там все по сложнее немного, не всю выборку - это факт, так бы скрипты не работали с БД у которых данных - гига(тера)байты, памяти не хватит.
Суть вобщем это не меняет, в твоем вопросе о потоках - одни дескрипторы, и потоками не пахнет.
Каждый сеанс для каждого клиента индивидуальный. Как в прочем и для других КС (не только веб) приложений.
1. Клиент через форму запостил файл на сервер, веб сервер его кладет в папку tmp или другую,
ему по сути по барабану кто обрабатывает получение файла, пхп, перл или другое цги.
Все это происходит именно в веб сервере. Можно файл запостить хоть в обычный хтмл файл, в темп папке он появится, и также, как темповый удалится.
Только при полном получении HTTP запроса от клиента (браузера) происходит обработка запроса и передача его в цги,
в который уже передается результаты веб сервера по загрузке файла и прочему. По другому быть не может, передаваемый файл - как и куки это всего лишь запрос.
Как можно запустить обработку запроса не получив оного с полу кукой или полу файлом к примеру? Есть передачи запроса пачкованием, но сути не меняет, пачки склеиваются в веб сервере. а потом обрабатываются уже настроенным ЦГИ
2. Неужели поменялась политика браузеров? Что, уже можно тырить файлы с клиента при помощи xmlhttprequest? Как вы файл то им отдадите данной технологией?
3. При fopen - это дескриптор, указывающий на начало файла и текущее смещение при чтении или записи.
Файл не грузится в память полностью, ты можешь его читать по байту (символьно) или пачками (строками) соотв. получаешь свое кол - во байт в приложении (скрипте),
условно память выделяется тока под твое кол - во байт.
4. Сокеты, в сис вызовах - это тот же файловый дескриптор.
Клиент получает от сервера данные, сервер к примеру отслылает 100 байт, клиент смог получить тока 30 из за тормознутости сети,
клиент серверу об этом говорит, получил 30. Сервер отправляет повторно сместившись на 30 байт.
Если ни тот не другой ничего не получают, тоесть висят, они могут висеть вечно, или пока кто нить не отвалится.
5. Базы данных и подобные (ftp, ssh, pop, imap, smtp и т. д.), это то же сокет соединение, со своими командами, и разными состояниями/командами/ответами
При выборке - БД формирует результат, и он хранится на стороне сервера а не в клиенте (в данном случае, клиент - PHP).
База так же отдает запись (по команде fetch_*) и смещается на след запись как и в файле,
тока там все по сложнее немного, не всю выборку - это факт, так бы скрипты не работали с БД у которых данных - гига(тера)байты, памяти не хватит.
Суть вобщем это не меняет, в твоем вопросе о потоках - одни дескрипторы, и потоками не пахнет.
Redjik
прозевал я тему, но обьяснили вроде,stdin,out error...
а также последний пост с pipe, это как раз перевод stdout одного потока в stdin другого, даже если первый еще в работе ....
походу один плюет данные другой их собирает и обрабатывает...
возможно
поможет осознать это
а самое большое просветление было у меня когда строился простой репликат базы данных
а еще 1>&2 (если не ошибся) когда stdout кидаем в stderror чтобы не показывать результат напрямую
или ./script > /dev/null
.....и в эту секунду должно быть понятно как работает readfile
прозевал я тему, но обьяснили вроде,stdin,out error...
а также последний пост с pipe, это как раз перевод stdout одного потока в stdin другого, даже если первый еще в работе ....
походу один плюет данные другой их собирает и обрабатывает...
Код:
ls -la|wc -h
php fetch_sql.php | mysql -u ... | php parse_result.php
Код:
tail -f /var/log/mysql_logа самое большое просветление было у меня когда строился простой репликат базы данных
Код:
tail -f mysql_bin_log | mysql replicateили ./script > /dev/null
.....и в эту секунду должно быть понятно как работает readfile
