вроде разделяемой памяти у нас нету

https://github.com/fabiokung/shm Рабочая или нет, не знаю.

при желании можно и на пхп сделать мультитрединг, но зачем гемороится с этим, если для этого есть более подходящие инструменты

Если язык хорош только в чем то одном. То это плохой язык

Если язык хорош только в чем то одном. То это плохой язык

звучит как-то по-джаваскриптовому

если язык пытается быть хорошим везде - то он везде плохой или средненькой говнистости.

https://github.com/fabiokung/shm Рабочая или нет, не знаю.

только под nix? не гоу вей :)

только под nix? не гоу вей :)

а чисто интересно, зачем в гошке нужно уметь шарить память между процессами?

если язык пытается быть хорошим везде - то он везде плохой или средненькой говнистости.

Тру

а чисто интересно, зачем в гошке нужно уметь шарить память между процессами?

ну например у тебя пару процессов "воркают", а один "собирает". Причем можно динамически включать выключать

конечно можно и через tсp общатся

только под nix? не гоу вей :)

Ну если захотеть можно и под венду сделать. Просто это никому наверное особо не надо.

Есть какие нибудь каноничные книги/туториалы по го чтобы пропустить воду про циклы и условные операторы, и написать какое нибудь приложение?

Можете посмотреть мой курс https://www.coursera.org/learn/golang-webservices-1 https://www.coursera.org/learn/golang-webservices-2 Там конечно есть про циклы и условия, но это вполне можно пропустить Домашки там так построены, чтобы почти всё в го попробовать, пара прямо приложений есть во 2-й части, с тестами

Из книг рекомендую Кернигана, Язык программирования Go

ну например у тебя пару процессов "воркают", а один "собирает". Причем можно динамически включать выключать

(я не очень умный), а чем здесь горутины с каналами сломаны?

Если язык хорош только в чем то одном. То это плохой язык

да ты че? а молотком нельзя шурупы заворачивать, че плохой инструмент чтоле?

(я не очень умный), а чем здесь горутины с каналами сломаны?

между процессами?

они работают только в одном процессе

между процессами?

нет, для задачи "слушаем и обрабатываем в разных местах"

Из книг рекомендую Кернигана, Язык программирования Go

У вас какие-то уведомления, если кто-то спрашивает про почитать? )

коллега

у тебя процессы же в пределах одного хоста.

да

если вы уже исчерпали возможности горутин и каналов - вы исчерпали возможности хоста

и вам прямая дорога в tcp/ip

нуу...

еще локальные сокеты конечно

для быстроты

Ну можно и напрямую через сетевую карту пакеты слать. ?

это оставьте сишникам

они работают только в одном процессе

в одном процессе, но в разных тредах.

я так и не понял, почему нужно разделять код на процессы, если он настолько тесно связан

они работают только в одном процессе

А зачем тебе несколько?

я так и не понял, почему нужно разделять код на процессы, если он настолько тесно связан

Чтобы жизнь была веселей. )

Чтобы жизнь была веселей. )

ну это понятно, но это не для го, это для развлекательных ЯП

нуу бывает необходимость

нуу бывает необходимость

Какая?

несколько парсеров условно, и один синхронизатор

несколько парсеров условно, и один синхронизатор

почему это не в разных горутинах и одной горутине синхронизатора? :)

клиенту не надо все сразу запускать

ему охото отдельные exe :)

ах, клиенту...

пусть займется чем-нибудь другим

если мы синхронизатор пролинкуем к каждому сборщику

будет оверхед

А+Sync B+Sync

будет оверхед

Какой?

ну какой блин, каждый процесс автономно хреначит синхронизацию

нагрузка на конечный хост X2

три воркера - X3

...

а?!

коллега, вы кому на уши хотите лапши навешать?

синхронизация может работать в один поток только, если мы в каждом демоне запустим свой - пиши пропало

бекенд на той стороне умрет

я ничего не понял. о какой синхронизации речь?

да господи, ну restapi например

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

Есть программа А и программа Б, они собирают некие данных, которые надо отправить на restapi

если они оба начнут собирать и отправлять, рест апи падает

ну пусть отправляют, в чем проблема?

если они оба начнут собирать и отправлять, рест апи падает

ну так тем более в одном процессе удобнее троттлить

если они оба начнут собирать и отправлять, рест апи падает

ах у нас api говно?!

ну пусть отправляют, в чем проблема?

вы походу не работали с "интерайз" кодом, которые переваривает только 1 rps

тогда его и переписать. пусть тротлит на своей стороне

он от третьей стороны

черный ящик

вы походу не работали с "интерайз" кодом, которые переваривает только 1 rps

не поверишь, всю неделю писал эту хуйню

вот ровно о чем ты говоришь

ERROR: S client not available

ну воткните прокси между ними

один процесс, внутренняя очередь, отдельный пул горутин, который разгребает очередь

@ruelephant а что таки мешает сделать все в одном бинаре и на горутинах? Но запускать их по конифгу там

workers=100500 - запустил 100500 воркеров

@ruelephant а что таки мешает сделать все в одном бинаре и на горутинах? Но запускать их по конифгу там

заказчик крутит все на дохлом ноуте, он перегревается если обе программы запущены :)

поэтому он запускает/закрывает

ну так тебе всё равно надо все их запускать

а синхронизатор весит постоянно

поэтому он запускает/закрывает

Морду с переключателем :)

ну понеслось конечно

заказчик крутит все на дохлом ноуте, он перегревается если обе программы запущены :)

я правильно понимаю, что вы беспокоитесь о производительности синхронизатора для 1 rps ?

подскажите, а что лучше для websocket использовать: gorilla или https://godoc.org/golang.org/x/net/websocket или ещё что-то?

я правильно понимаю, что вы беспокоитесь о производительности синхронизатора для 1 rps ?

я не беспокоюсь, я гарантированно могу сказать что запуск двух воркеров сразу убьет его

поэтому воркеры сначало сливают на сихронизатор

а он разгребает уже

подскажите, а что лучше для websocket использовать: gorilla или https://godoc.org/golang.org/x/net/websocket или ещё что-то?

гориллу В этом пакете даже об этом сказано

так зачем вам шаред мемори тогда?

я не беспокоюсь, я гарантированно могу сказать что запуск двух воркеров сразу убьет его

а как он его убивает, если GOMAXPROCS не выкручен? по памяти?

если у вас процессы один за другим предполагается запускать по очереди, то какой тут шаред-мемори?

гориллу В этом пакете даже об этом сказано

последний коммит в gorilla был месяц назад, это нормально?

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

я не беспокоюсь, я гарантированно могу сказать что запуск двух воркеров сразу убьет его

о, да. конечно. прям убьет.

да блин

удаленный сервер на ASP.NET

ну и че

последний коммит в gorilla был месяц назад, это нормально?

в протоколе не каждый день появляется что-то новое

ресурсы машины вырезаны до целерона

ну и?

и реально падает

в протоколе не каждый день появляется что-то новое

понятно

а как падает-то? что происходит?

падает если программер криворукий