LINUX.ORG.RU

История изменений

Исправление gh0stwizard, (текущая версия) :

Иногда, но не в этом случае.

Случаи бывают разные. Например, один поток выкачивает из БД данные и записывает их в кучу или в shm или кидает референс через канал. Другой поток должен данные считать, подгрузить на основе них файл и изменить их еще раз. Так вот сколько бы коросов внутри каждого потока не было создано, CSP не спасет от необходимости блокировать участок памяти на изменение. В случае TCP и сериализации данных оба процесса могут изменять данные независимо друг от друга, при этом изменненные данные приходят в опять же в сериализованном виде и такие данные даже нет смысла накапливать, пока другая сторона барахтается и еще не дошла до готовности принять снова данные из канала. Иными словами CSP дает жесткую привзяку к синхронизации данных, в то время как решения на TCP оставляют выбор программисту. Данные можно пропускать, записывать в свою sqlite, bdb базу и разгребать по мере необходимости. Вобщем задачи бывают разные и реализации тоже. То, что для тебя CSP это панацея не означает, что го идеальный язык, в гугле работают неидеальные люди.

сделанный специально для распределенных задач

А серверные приложения сюда не попадают по-твоему ? :)

P.S Сравнение C vs Asm были актуальны 30 лет назад. Сейчас компилятор оптимизирует код так, что только супер профи по асму сможет написать код быстрее, надежнее или съедающий меньше памяти.

Исходная версия gh0stwizard, :

Иногда, но не в этом случае.

Случаи бывают разные. Например, один поток выкачивает из БД данные и записывает их в кучу или в shm или кидает референс через канал. Другой поток должен данные считать, подгрузить на основе них файл и изменить их еще раз. Так вот сколько бы коросов внутри каждого потока не было создано, CSP не спасет от необходимости блокировать участок памяти на изменение. В случае TCP и сериализации данных оба процесса могут изменять данные независимо друг от друга, при этом изменненные данные приходят в опять же в сериализованном виде и такие данные даже нет смысла накапливать, пока другая сторона барахтается и еще не дошла до готовности принять снова данные из канала. Иными словами CSP дает жесткую привзяку к синхронизации данных, в то время как решения на TCP оставляют выбор программисту. Данные можно пропускать, записывать в свою sqlite, bdb базу и разгребать по мере необходимости. Вобщем задачи бывают разные и реализации тоже. То, что для тебя CSP это панацея не означает, что го идеальный язык, в гугле работают неидеальные люди.

сделанный специально для распределенных задач

А серверные приложения сюда не попадают по-твоему ? :)