Многопоточность/многопроцессорность в kore.io

https://docs.kore.io/4.0.0/arch.png

видел, только понятно с этого мало. Ну запускается несколько процессов, я думал, что каждый возьмет на себя каждый из запущенных серверов (слушать порт и тп). В общем, я не понимаю задумки. Еще написал подобный вопрос в мейлинг лист кора, ответ сюда продублирую.

В предыдущих темах спрашивали причину выбора этого сервера? Можно кратко или ссылку на комментарий.

Дескриптор файла сокета можно передавать меж процессами по unix domain socket сисколом sendmsg. Теоретически один сокет можно читать/писать из разных процессов.

Не спрашивали. Наверное из простоты ) и отстутсвия лишних абстракций. Ну просто доки дерьмо. И рассчитаны на то, что за плечами у меня 100500 фреемворков. В целом мне все понятно, но с потоками в самом коре у меня конкретное непонимание, делать ли синхронизацию или не надо … Сижу и гадаю.

Тут еще прикол такой - пытался заставить работать второй процесс, первый после получения get запроса ушел ждать сигнала от condition_variable (уснул навечно), на другой порт в это время шли другие запросы, результат - другой процесс даже не и не думал начинать что-то делать ))

Отэта норм я прошел мимо.

struct kore_worker {
	u_int16_t			id;
	u_int16_t			cpu;
	int				running;
#if defined(__linux__)
	int				tracing;
#endif
	pid_t				pid;
	int				pipe[2];
	struct connection		*msg[2];
	u_int8_t			has_lock;
	int				restarted;
	u_int64_t			time_locked;
	struct kore_module_handle	*active_hdlr;

	/* Used by the workers to store accesslogs. */
	struct {
		int			lock;
		size_t			offset;
		char			buf[KORE_ACCESSLOG_BUFLEN];
	} lb;
};

...

void
kore_worker_init(void)
{
...
	len = sizeof(*accept_lock) +
	    (sizeof(struct kore_worker) * worker_count);

	shm_accept_key = shmget(IPC_PRIVATE, len, IPC_CREAT | IPC_EXCL | 0700);
...
}

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

Однако же, листая их сайт и доки у меня снова и снова возникал вопрос: а на кой черт эта штука вообще нужна? Это похоже на попытку велосипедостроения от людей, которые не осилили более серьезные решения (например, nginx). На картинке показано, что якобы блокировка слушающего сокета передается по кругу — в действительности очередность определяется методом «кто первый встал — того и тапки». При этом все сокеты в один момент времени может слушать только одир рабочий процесс, что снижает нагрузку, но увеличивает задержку: при получении соединений с нескольких сокетов нужно ждать, пока текущий рабочий процесс получит соединение и отдаст блокировку второму процессу, тогда второй процесс сможет сделать epoll по всем сокетам и достать второе соединение. Nginx в этом случае одновременно просыпается всеми процессами и через мутексы назначает каждому сокету по одному процессу.

Если же идти в вопросах дальше, то мне становится непонятно, почему они вообще взяли именно такую модель. Например, почему они вообще получают соединения несколькими рабочими процессами? Особенно когда у тебя один хрен в один момент времени только один процесс может слушать сокеты. Почему бы не получать соединения главным процессом и раздавать их в общую память для последующей параллельной обработки рабочими процессами?

но нет, все запросы обрабатываются одним процессом, более того - одним потоком

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

Сишный модуль, который я пишу, он всегда выполняется одним потоком (ну если я сам ничего не запускаю руками, черза task’и kore’а, например), т.е. мне не нужно заморачиваться со всякой синхронизацией ожидая какой-нибудь лихой поток, который все сломает?

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

видел, только понятно с этого мало. Ну запускается несколько процессов, я думал, что каждый возьмет на себя каждый из запущенных серверов (слушать порт и тп). В общем, я не понимаю задумки. Еще написал подобный вопрос в мейлинг лист кора, ответ сюда продублирую

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

Тут еще прикол такой - пытался заставить работать второй процесс, первый после получения get запроса ушел ждать сигнала от condition_variable (уснул навечно), на другой порт в это время шли другие запросы, результат - другой процесс даже не и не думал начинать что-то делать

Хех, то есть, оно все-таки еще и нерабочее.

Ответили в Mailing List’е

Kore worker processes are spawned, one for each CPU in your system. By default they are also pinned to them.

You control this with the worker config option.

Each worker is able to handle up to worker_max_connections in client connections.

Each worker serves all configured servers and domains.

You saw only one worker handle your requests simply because it wasn’t busy enough for other ones to take over.

Every worker is single threaded and stands alone. Your module code is loaded on each. If you want to share data use shared memory that you setup yourself.

.joris

Из основного: 1. каждый worker будет работать со всеми сконфигурированными доменами, количество воркеров можно настраивать (хоть один). 2. Каждый воркер однопоточный. 3. Я не заметил блог проекта, там есть доп инфа по разным вопросам https://blog.kore.io/

Однако же, здесь нет ответа на вопрос «почему зависший в обработке запроса процесс кладет второй рабочий процесс».

Жестко очень ). Нормальный проект же, в сравнении с современными монстрами … По поводу «почему соединение не подхватилось другим воркером» - там такая ерунда

worker_max_connections 	

The maximum number of active connections a worker process holds before refusing to accept more.

Т.е. оно как-то считает активные соединения, не хватало в моем случае (детали не знаю, соединения ведь и закрываются, хз).

Видимо каждый процесс хапает себе пачку входящих соединений и идет обрабатывать. Т.е. без множества запросов от кучи клиентов не будет никакой тучи соединений и воркер просто не отдаст право брать подключения. О удачности решения я бы тоже так однозначно не говорил - разве лучше, когда куча потоков будет постоянно брать мьютексы при плевой нагрузке? Пока наргузки нет, пусть один работает свободно.