bernex: сколько не вчитывался так и не понял какой из алгоритмов вам в принципе нужен. Если как-то перефразирую могу попробовать подсказать варианты.
Если есть 10 клиентов которые коннектятся к серверу и запрашивают некие 40000-100000 значений то не понятен принцип разбивки этого общего пула даных. Ну пусть они себе каждый в своей горутине чего-то забирают из []uin64 и без записи там считай не конкарерт никакой.
Если нужно прямо каждому выделить уникальный кусочек то нужно понять по сколько выделять (количество клиентов же не обязательно будет ровно 10, хотя кто вас знает) и пусть функция вытаскивания высчитывает какой диапазон слайса вам нужен, доставать так Data[start_i: start_i+count] и как бы всё. Мало данных в общем что бы что-то особо осязаемое предлагать.
А ну и в принципе не понятно же кому какой диапазон (если клиенты их заранее не указывают) то нужен счётчик, кто первым приконнектился тот более мелкий start_i и получает.
Тот случай когда вначале, наверное, лучше передать в горутину поинтер на []unit64.
Но в целом... идея так себе, не предполагает даже RWMutex что бы защитить чтение от возможной записи (данные ведь где-то добавляются)
Вариант сделать так:
N горутин - читаем из канала всеми горутинами
for k, v := range Data { отправляем в канал}
Таким образом распределяем данные по разным горутинам. Но в целом... если прямо из примера смотреть - то в чём вообще смысл горутин-то? Разве что несколько ядер - тогда нужно это как-то особенно определить - запустить не две горутины, а сразу столько сколько ядер.
lelvisl: если будете передавать конфиг в каждую функцию то посмотрите на то что бы передавать конфиг в пакет в одном месте, а уже в рамках пакета использовать внутреннюю переменную. Указатель или обычную - это уже как решите.
Никита: Так же надо указать что работа с каналами будет превращать доступ к данным из многотопочного в однопоточный и в случае если конфиг большой и его нужно скажем весь обновить могут быть долгие локи если об этом не позаботиться заранее, но в целом вы правы указав эти варианты:)
Александр Павлюк: к примеру вы выбрали глобальные переменные - что будете делать с конкуретным доступом? Может быть сейчас вас устроит:
1. записать данные в переменную в func init()
2. везде и всюду только читать
Но пройдёт какое-то время и вам захочется туда чего-нибудь записать. Или ещё чего.
Александр Павлюк: на самом деле влияет. От того как вы на них для себя отвечаете зависит какой из вариантов хранения и обработки данных вы выберите. Конфиги по своей сути кажутся простыми, пока не касаешься их проектирования.
Попробуйте углубиться в мобильную разработку. Там и новичков в целом любят и разработчики всегда нужны. Прокачайтесь в том до чего сможете дотянуться - потом в компанию на вакансию....
Новая Windows вам поможет делать приложения сразу для всех платформ с этой операционкой, само по себе знание этой экосистемы - скорее плюс. Но к ней в довесок нужно Java (Android), хотя бы поверхностные знания Си/Си++ для всякой математики и алгоритмов не зависимых от платформы.
Напишите в твиттер Лев Добров @yandexmail опишите проблему и может быть вам ответят. Для большего эффекта сделайте публичный твит указав в начале сообщения какой-нибудь тег #support #yandex #error или что-нибудь в этом роде.
Silm: я пишу на Golang, раньше писал на PHP и добавлял Си там где это давало стократный прирост.
По поводу моего ответа, я за второй вариант, который "разделить код на множество отдельно описанных классов выполняющих отдельные изолированные функции" потому что так читать, проверять и выполнять проще. Меньше ошибок. Но вы, вероятно, поняли мой ответ в точности наоборот.
Не советую скидывать весь PHP код в одну кучу... почему - попробуйте разобраться сами:)
beduin01: суть похожа, но синтаксис у D не такой локоничный. А это значит что вероятность ошибки в коде на D выше. Как в том что пишете лично вы так и в том что вы на веру берёте из других репозитариев. В Golang это проще контролировать.
Посмотрев другие работы IBM Watson в работе был удивлён очень скудной выборкой вариаций. Как по мне так рекламные ролики выглядят куда лучше живых приложений на основе их системы.
Да они могут напрограммировать робота который будет обыгрывать в шахматы или ставить диагнозы, но по сути это ручной труд - заставить это всё работать. Я же ищу поставщика данных.
Делать анализ страничек и поведения пользователя можно и без Ватсона.
Если есть 10 клиентов которые коннектятся к серверу и запрашивают некие 40000-100000 значений то не понятен принцип разбивки этого общего пула даных. Ну пусть они себе каждый в своей горутине чего-то забирают из []uin64 и без записи там считай не конкарерт никакой.
Если нужно прямо каждому выделить уникальный кусочек то нужно понять по сколько выделять (количество клиентов же не обязательно будет ровно 10, хотя кто вас знает) и пусть функция вытаскивания высчитывает какой диапазон слайса вам нужен, доставать так Data[start_i: start_i+count] и как бы всё. Мало данных в общем что бы что-то особо осязаемое предлагать.
А ну и в принципе не понятно же кому какой диапазон (если клиенты их заранее не указывают) то нужен счётчик, кто первым приконнектился тот более мелкий start_i и получает.