Анкенту влом заполнять. Я вроде числюсь в ИТМО, мб меня и так пустят =D

нет, ее надо заполнить, организатор не итмо

нет, ее надо заполнить, организатор не итмо

Да чет они дохуя вопросов задают. Больно любопытные.

Да чет они дохуя вопросов задают. Больно любопытные.

киньте анкету

у меня вк заблочен

у меня вк заблочен

https://goto.msk.ru/camp_autumn/

спасибо

да вроде не так много вопросов

но да, собирают базу для рекрутинга

мне кажется если ты напишешь минусы

тебя все равно пригласят

мне кажется если ты напишешь минусы

ват?

ну типа там где обязательное поле, просто оставишь минус, если не хочешь делиться инфой

М, так и сделаю. Если не пригласят, я не сильно расстроюсь :)

но лично я не знаю, чем это тебе навредит, если поделишься инфой о себе рекрутерам

Просто ВЛОМ

Никто не слышал о реализациях синхронных протоколов для IPC?

точнее, главное чтоб синхронным было API. Понятно что внутря будет асинхронщина

хотя я наверное не правильно описал, ибо под это описание подходят даже сокеты с блокирующим IO. Хотелось бы имитировать генераторы, только в IPC. Т.е. не просто отправку, а отправку и получение результата (на одной стороне) А на другой вечный цикл ожидающий заданий

N потоков на N запросов тогда будет

В чем смысл асинхронности при синхронном интерфейсе?

Все равно ж будешь главный поток блокировать этим синхронным интерфейсом

Так же как в го сделать не получится

В чем смысл асинхронности при синхронном интерфейсе?

IPC ж

изоляция

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

дешевой в плане потребления времени

Да какая разница? Синхронный интерфейс с ожиданием ответа == блокировка потока. Ты можешь из N потоков просто использовать сокет с jsonrpc каким-нибудь

То ж самое будет

Ну или объясни на чем тут будет экономия времени?

меня интересует именно формат "запрос-ответ", 1 к 1 Существует ли что-то готовое для такого узкого кейса.

ладно, забей на мой исходный вопрос.

насчет экономии времени

У меня мак завис, перехожу на телефон

тут не экономия времени, а скорее скорость реагирования важна

Короче хочется rpc. Который будет оптимизировн для такой узкой задачи, и задержка между "вызовами" была сравнима с нативный вызовом функции

Так более понятно?

тот же zeromq даст это

он дурацкий правда

Но zeromq разве не асинхронный?

внутри да, но Req-Rep сокеты вполне синхронные

т.е. его можно использовать синхронно

че такое реп реп сокеты

в двух словах обьяснить?

их абстракция над сокетами

там у каждого сокета есть свой тип Request, Reply, Push, Pull, Dealer, Router

со своими свойствами, и из них можно делать сеть удовлетворяющую требованиям

спасибо я гляну в zmq. но почему-то мне кажется что это все равно немного не то

а их сокеты поверх обычных?

да

а вообще у тебя кто общаться будет?

два процесса, сервер и клиенты

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

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

этот алгоритм синхронный

локально не важно пока по платформе, сейчас просто обзор

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

да, это будет только локально, про это и речь

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

т.е. есть условно 1 кпу тупо для ядра и 1 кпу для дочернего процесса

а там частое общение? т.к. shmem => поллинг ручной

иначе какие-нить eventfd/futex и таки придётся сисколы делать

ориентированность на частое общение

+

да, я смотрю в nano message и правда Rep-Req очень похоже на то что я хочу х)

Правда я хочу только это, и в идеале оптимизировать для большого количества rep-req

В качестве велосипедного бреда: можно взять какой-нибудь быстрый бинарный serde, обмазаться shm и синхронизировать это всё через pthread_condvar

так не хочу ж я сисколы

по этому pthread вроде как не

Как ты будешь делать IPC без сисколлов?

read/write это тоже сисколлы

mmap

или как там

Это сисколл

Привет

1

это инициализация

при инициализации

pthread это не сисколлы

mmap +анонимный, плюс послать его fd по unix совету другим тредам