[must-read repost] Обманчиво простая задачка или немного про системное программирование

Nov 23, 2013 07:30

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

Я в свое время славно походил по этим граблям, и у других их видел в количестве.

Оригинал взят у zamotivator в Обманчиво простая задачка или немного про системное программированиеВыношу из своего поста и ( Read more... )

repost, программирование, must-read

Leave a comment

Comments 68

mudasobwa November 23 2013, 06:31:03 UTC
А семафоры придумали тру́сы, да? Никогда не бывает `sleep` разумным. Никогда. Ну, пока ты не внутри драйвера флешки, конечно, да и то - и там давно придумали нормальные механизмы.

Reply

wizzard0 November 23 2013, 08:03:52 UTC
Кхм. Речь не о семафоре. Если говорить о семафоре с людьми, которым нужно срочно поговорить с подпроцессом, то за деревьями не будет видно леса.

Reply

nponeccop November 23 2013, 10:14:44 UTC
в данном конкретном случае семафор - рукалицо. Пайпы вполне самодостаточный механизм синхронизации, чистый message passing же.

Reply

wizzard0 November 23 2013, 11:48:15 UTC
Типа того.

Reply


max630 November 23 2013, 09:40:35 UTC
я не очень понимаю, зачем нужно читать всю эту беллетристику. Всё что нужно написано в man select и дальше по see also

да и в комментах по большей части какой-то нерелевантный трёп

Reply

nponeccop November 23 2013, 09:59:15 UTC
man select это ебаный стыд, в 2013 году-то. В 1990-х это конечно был ультра-хайтек (стандартные сокеты только появились), в 2000-х - элитным евентодрочерством, но сейчас-то.

libev как минимум!

Reply

max630 November 23 2013, 13:00:54 UTC
этих libev-ов по штуке в каждом UI фреймворке сейчас. И в каждом какие-то косяки. В общем, знать как оно внутри устроено как правило пригождается

Reply


nponeccop November 23 2013, 09:56:36 UTC
Единственное* нормальное решение - это евент-луп библиотека с промисами или чем-то получше (reactive properties, reactive event streams, ...) Остальное - годится и "оно же работает"™, но в-общем, ёбаный стыд в соответствии с тезисом "sleep никогда не бывает разумным ( ... )

Reply

wizzard0 November 23 2013, 11:49:56 UTC
> буферы недостаточного размера.
тут мы начинаем вспоминать про C10K и прочее веселое.

ну, точнее, даже C1K становится интересным вопросом, если линк к серверу 10GE и надо не висеть холостым коннектом а очень даже хуячить

Reply

nponeccop November 23 2013, 12:30:29 UTC
Наиболее печально, как мне кажется, в области юзер интерфейса и обычных аппов и сайтов. О хай-теке беспокоиться не надо, он сам справится.

Ассумпшены 10-летней давности о соотношении производительности разных компонентов системы не соответствуют действительности.

IO и CPU внезапно столько, хоть обожрись, а количество приложений, которые в состоянии их утилизировать - нулевое. Всё пишется, как будто у нас 1980-е на дворе, я хуею, дорогая редакция.

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

http://farmanager.googlecode.com/svn/trunk/unicode_far/findfile.cpp

// Открываем файл ( ... )

Reply

wizzard0 November 23 2013, 13:09:23 UTC
ну да, поэтому фар выбрасываем нахуй и юзаем Everything, который отсканивает мои 8 млн файлов за 15 секунд и потом ищет за <30ms

Reply


kray_zemli November 23 2013, 11:52:14 UTC
Пайпы -- это для системных программистов. Есть же mmap

Reply

wizzard0 November 23 2013, 11:57:08 UTC
mmap api в php? :)

Reply

kray_zemli November 23 2013, 11:57:58 UTC
Тогда файлы, как во времена мультилинейных BBS.

Reply

nponeccop November 23 2013, 12:41:14 UTC
Во-первых, http://php.net/manual/en/ref.shmop.php и т.п Именно mmap конечно нет, но только потому, что никто не написал биндинг ибо п.3

Во-вторых, на это с другой точки зрения посмотреть надо. mmap для IPC - это же shared state, а пайпы - это message passing. Если у нас не hello world, со shared state без message passing библиотеки вокруг хлопот не оберёшься.

Уровень дискуссии конечно поражает.

Reply


kray_zemli November 23 2013, 11:54:00 UTC
Да, кстати, в синхронном режиме код из поста нормально будет работать, т.е. если мы уверены, что пишем ровно по 1 запросу и читаем ровно по 1 запросу.

Reply

wizzard0 November 23 2013, 11:57:53 UTC
> если мы уверены, что пишем ровно по 1 запросу и читаем ровно по 1 запросу.

Неверно. Причина 1: буфера в ядре не бесконечного размера.

Reply

kray_zemli November 23 2013, 12:00:04 UTC
Да какой бы ни был буфер. Мы пишем запрос тогда, когда второй поток готов его прочесть. Разблокируются в конце-концов оба потока. Потом мы читаем ответ от второго, зная, что он рано или поздно его пришлёт.

Reply

nponeccop November 23 2013, 12:44:03 UTC
> Неверно. Причина 1: буфера в ядре не бесконечного размера.

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

Reply


Leave a comment

Up