Сегодня Google выпустила новый Asynchronous JavaScript and XML (AJAX) API, призванный помочь AJAX-разработчикам более лёгкий путь интеграции Atom и RSS-фидов в веб-приложения или блоги.

В дополнение к Хабратопику месячной давности
— практический пример использования API
Подключаем "прямой эфир" Хабрахабра:
<style type="text/css">
#feedControl {
width: 400px;
margin: 20px;
}
</style>

Возникла задача из php://input скопировать данные в нужный файл.
Решил проверить на быстродействие возможные способы копирования файла размером 9 мегабайт из php://stdin.
Их несколько:

• Чтение блоками через fread() и запись через fwrite()
• Запись содержимого используя file_put_contents() данных, полученных с помощью file_get_contents()
• Копирование с использованием функции копирования файлов copy()
• Использование stream_copy_to_stream(). появилась в PHP5

Примечание: ниже перевод статьи «On Streaming, Chunking, and Finding the End», в которой авторы рассматривают процесс передачи информации по HTTP-соединению и возможности для ускорения этого процесса. Мои комментарии далее курсивом.

Два способа передачи

Как и в большинстве механизмов передачи данных, в HTTP существует два основных способа отправить сообщение: «все и сразу» или «по частям». Другими словами, в HTTP есть возможность отправлять данные до тех пор, пока еще есть хотя бы что-то, что можно отправить, либо отправить все данные как одну логическую единицу, указав предварительно ее размер.

Если вы занимаетесь веб-разработками достаточно продолжительное время, скорее всего, вы уже знаете, как работает сброс буфера (flush) на стороне сервера. Этот метод позволяет начать отправку части данных пользователю, в то время как скрипт может продолжать выполнять некоторые, достаточно медленные, действия (скажем, ресурсоемкий запрос к базе данных). Если вы уже применяли эту возможность, тогда вы, вероятно, использовали преимущества потокового (streaming) механизма, хотя могли и не знать всех деталей работы HTTP-протокола.

читать дальше на webo.in →

Обзор моделей работы с потоками

Многие люди не понимают того, как многопоточность реализована в различных языках программирования. В наши времена многоядерных процессоров такое знание будет весьма полезно.
Вот вам небольшой обзор.

Здравствуйте дорогие читатели. В данной статье мы рассмотрим различные потоковые модели, которые реализованы в современных ОС (preemptive, cooperative threads). Также кратко рассмотрим как потоки и средства синхронизации реализованы в Win32 API и Posix Threads. Хотя на Хабре больше популярны скриптовые языки, однако основы — должны знать все ;)

Навеяно предыдущей статьей на эту тему.
Для того чтобы, структурировать свое понимание – что представляют собой threads (это слово переводят на русский язык как «нити» почти везде, кроме книг по Win32 API, где его переводят как «потоки») и чем они отличаются от процессов, можно воспользоваться следующими двумя определениями:

• Thread – это виртуальный процессор, имеющий свой собственный набор регистров, аналогичных регистрам настоящего центрального процессора. Один из наиважнейших регистров у виртуального процессора, как и у реального – это индивидуальный указатель на текущую инструкцию (например, индивидуальный регистр EIP на процессорах семейства x86),
• Процесс – это в первую очередь адресное пространство. В современной архитектуре создаваемое ядром ОС посредством манипуляции страничными таблицами. И уже во вторую очередь на процесс следует смотреть как на точку привязки «ресурсов» в ОC. Если мы разбираем такой аспект, как многозадачность для того, чтобы понять суть threads, то нам не нужно в этот момент думать о «ресурсах» ОС типа файлов и к чему они привязаны.

Очень важно понять, что thread – это концептуально именно виртуальный процессор и когда мы пишем реализацию threads в ядре ОС или в user-level библиотеке, то мы решаем именно задачу «размножения» центрального процессора во многих виртуальных экземплярах, которые логически или даже физически (на SMP, SMT и multi-core CPU платформах) работают параллельно друг с другом.

Итак… Приступим.
В последнее время я встретил сразу 2 реализации многопоточности на Хабре. Немного подумав я решил написать и свой вариант.
Но так как у меня нет возможности использовать PCNTL библиотеку, то мне пришлось извратиться…

Задача: реализация многопоточности на PHP (threads)

Издержки: нет модуля PCNTL ( build w/o PCNTL )

Решение: чистый PHP + Unix ( pure PHP + Unix )

Или об особенностях управления отдаваемым контентом в PHP.

Поводом для данной статьи послужило двухдневное исследование, результаты которого показали, что безобидные по своей производительности функции echo и print на самом деле могут работать очень долго и их производительность зависит от качества интернета конечного пользователя.

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

На собеседовании в ИТ-компании было предложено ответить на следующий вопрос.

Задача. Дано такой код:

		static int counter = 0;

		void worker()
		{
			for (int i = 1; i <= 10; i++)
				counter++;
		}

Процедуру worker() запускают из двух нитей. Какое значение будет содержать переменная counter по завершении работы обеих нитей и почему?

Немного теории. Нити — это параллельно-исполняемые задачи в пределах одного процесса. Основное различие между процессами и нитями такое, что все нити одного процесса работают в общем адресном пространстве своего процесса.

Я не называю нити потоками, что бы не путать потоки выполнения (thread) и потоки данных (stream).

Про потоки NTFS на хабре писали уже не раз, я же покажу, как с их помощью преодолеть одно ограничение Windows по работе с процессами. Тут эта тема в одном посте уже поднималась, но как-то вскользь. Я же хочу обратить на неё внимание.

Вы наверное знаете, что .exe файл работающего процесса невозможно удалить, пока он работает. Можно перемещать файл, но только в пределах своего раздела. С помощью потоков NTFS всё таки можно удалить файл процесса во время его работы.

Недавно мы ставили SDK для разработки под Qt for Symbian на Linux. Теперь пришло время что-нибудь написать на нем.
Сейчас практически везде используются многопоточные архитектуры для выполнения каких-либо фоновых расчетов в то время как пользователь использует UI.
Давайте разберемся, насколько это эффективно при разработке под Symbian.

Перевод главы «Multithreading» книги David Thomas и Andrew Hunt «Programming Ruby: The Pragmatic Programmers' Guide, Second Edition».

Часто самым простым способом выполнить одновременно две вещи является использование потоков в Ruby. Они являются внутрипроцессными, встроенными в интерпретатор Ruby. Это делает потоки Ruby полностью переносимыми, т.е. независимыми от операционной системы. Но в то же время вы точно не получите выгоду от использования родных, нативных потоков. Что это значит?

Вы можете столкнуться с голоданием (thread starvation — это когда поток с маленьким приоритетом не имеет шанса запуститься). Если вы хотите заблокировать ваши потоки, то со скрежетом остановится целый процесс. А если возникнет ситуация, что некоторые потоки будут посылать вызовы операционной системе, для выполнения которых требуется немалое время, то все потоки будут висеть, пока интерпретатор не получит контроль обратно. И наконец, если ваша машина имеет больше одного процессора, потоки Ruby не будут это использовать, т.к. они запускаются в одном процессе, а в одиночном родном потоке они будут вынуждены запускаться на одном процессоре единовременно.

Все это звучит страшновато. Тем не менее, на практике во многих случаях выгода от использования потоков во многом перевешивает любые потенциальные проблемы, которые могут возникнуть. Потоки Ruby являются эффективным и легким путем достижения параллельности в вашем коде. Вы просто должны понять основные проблемы реализации, и, соответственно, архитектуру.

Введение

В замечательной статье с trapexit «Building a Non-blocking TCP server using OTP principles» рассказывается, как построить неблокирующий TCP сервер используя принципы OTP. Думаю, каждый, кто начинал изучать elrlang рано или поздно сталкивался с этой статьей. Для построения неблокирующего TCP сервера в указанной выше статье используется недокументированный функционал из модуля prim_inet.

Не буду филосовствовать хорошо или плохо использовать undocumented features, в некоторых «костыльных» решениях это действительно нужно, в продакшене я бы предпочел использовать проверенные средства. На заметку, даже в самой статье автор предупреждает: "Examining prim_inet module reveals an interesting fact that the actual call to inet driver to accept a client socket is asynchronous. While this is a non-documented property, which means that the OTP team is free to change this implementation, we will exploit this functionality in the construction of our server [1]."

Продолжаю свои повествования об Android. И в этот раз хочу поделиться ценной информацией о процессах и потоках, которая должна быть хорошо усвоена и всегда оставаться под рукой во избежании ошибок и недопонимания при написании приложений. В конце статьи приведу пример реализации AsyncTask, который загружает в ImageView картинку по нажатию на кнопку.

Поскольку мой первый небольшой обзор операционной системы реального времени QNX показал, что среди жителей Хабра есть к ней интерес, то я решил продолжить цикл заметок. Мне кажется, что стоит немного рассказать о системной архитектуре QNX6. Думаю, что нелишне дать определение тому, что такое микроядро, и какие задачи оно решает. По ходу повествования будут также развенчаны два мифа, связанные с QNX. Но сначала…

Немного о POSIX

С выпуском каждой новой версии QNX (а надо отметить, что первая версия ОСРВ QNX появилась теперь уже в далёком 1981 году), разработчики использовали накопленный ранее опыт и делали систему лучше, в том числе и удобнее для разработчиков. Именно поэтому QNX Neutrino поддерживает стандарты POSIX 1003.1, например, управление потоками (threads), расширения реального времени (Realtime Extensions), дополнительные расширения реального времени (Additional Realtime Extensions) и профили прикладных окружений (Application Environment Profiles, AEP).

Зачем я об этом говорю?

Продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я хотел бы рассказать о планировании потоков в QNX6^*. Как уже известно читателям (которые ознакомились с предыдущей заметкой цикла), микроядро QNX6 управляет потоками, а не процессами. И именно микроядро осуществляет загрузку контекста того потока, который должен получить управление в следующий момент. Выбор потока, который будет выполняться процессором (т.е. активно использовать процессорное время) и есть планирование потоков.

Когда происходит планирование потоков

Микроядро QNX Neutrino не работает постоянно, а получает управление только в случае системных вызовов, исключений и прерываний. Также микроядро во время своей работы выполняет планирование потоков. Отсюда можно сделать верный вывод, что операция планирования потоков происходит не сама по себе, а по какому-то событию.

На хабре существует множество статей, посвящённых историям различных взломов, рекомендаций по генерации паролей и прочих основ информационной безопасности. Я решил внести и свою лепту, написав небольшой отчёт по исследованию одного из достаточно крупных сайтов, близкого к IT-тематике, в котором на фоне хорошей защищённости от основных методик взлома мной обнаружены совершенно банальные ошибки проектирования самой системы.

Подробнее о том, на что нужно обращать внимание при проектировании своих сайтов под катом.

Известно, что только 5% программистов в состоянии решать задачи многопоточного программирования. А в месте с тем, с ростом количество ядер даже у мобильных устройств потребность в использовании нескольких нитей возрастает многократно. С каждым днем появляются как новые языки программирования, специально предназначенные для решения специфических задач параллельного программирования, так и в уже хорошо известных и широко применяемых решениях появляются методы, которые не только облегчают понимание, но и сводят решение задачи к своеобразной поэзии программного кода.

Читая книгу “Идеальный код” под редакцией Энди Орама и Грега Уилсона мне довелось натолкнуться на интереснейшую задачу в главе посвященной параллельной обработке (гл. 24. стр. 444). В ней автор, Саймон Пейтон Джоунс, приводит решение на языке Haskell. Там же он утверждает, что существуют решения задачи Сата Клауса для языков Ada95 и Polyphonic C#. В силу профессиональных интересов несколько ранее мне приходилось обсуждать с коллегами возможности многопоточной Apple реализации для языка Objective-C.

Считается, что программировать нужно на уровне абстракций, а не “на языке”, но с тем же успехом можно искать красоту поэзии в эмоциях, а не в изяществе слога, выраженного посредством языка. Под катом предлагаю вместе со мной спеть песню тем, для кого языковая выразительность не пустой звук, а мелодия, будоражущая воображение.

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.