Паша, астанавись

Что бы ни делать, лишь бы через название процесса не общаться ;)

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

можешь ещё в сomm сходить и руками ёбнуть туда что нибудь

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

Вот и мне интересно

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

почему нельзя ipc сделать на тех же сигналах

или через шаредмем

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

В общем остается только именованые пайпы. Или неименованые.

вопрос с конкуретностью решается семафорами

ебать, а ты в имени процесса джейсон держать будешь ? )

это достойно 2017го но боюсь деды встанут из могил когда ты напишешь это

Про json отличная идея, но я хотел только 1 лексему держать

А так можно имя процесса использовать в качестве маленькой БД, вот это поворот

Следующий шаг после nosql

Главное что один процесс должен уметь считывать кастомную информацию о других процессах.

чем unix sockets не ок?

в n-1 раз меньше получится, чем пайпов

в comm можно напихать все, что угодно, при желании. список процессов будет прекрасен, а кое-что в юзерспецсе будет крэшиться от json-а в имени

изверги вы доводите мои идеи до абсурда

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

USR1 USR2 как раз

unreliable

точнуя задержка сильно зависит от hz и highres таймеров

если тебе не медленно, конечно, надо :)

Не, тут задержка ни при чем. USR1 это точка, USR2 это тире. Просто накапливаем их и потом десериализуем

а, ну да, норм

пока внешний шум не помешал

заблочить сигналы от неинтересных процессов можно, но не сильно весело

статус файл можно сделать, mmapнуть его в каждом процессе и фиксированной структурой заполнять

лочить ренджем апи есть

лочить ренджем апи есть

Залочка хуево работает. И требует опции монтирования. Лучше лочить flockом

А что там за задача была ?

Залочка хуево работает. И требует опции монтирования. Лучше лочить flockом

у flock свои проблемы

Например

задача не моя, не помню

А так можно имя процесса использовать в качестве маленькой БД, вот это поворот

Пффф. Курьер имап использует имена файлов как бд

Например

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

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

Упоролся ?

Флок один на файл

Упоролся ?

почитай

Уж я то про флок точно всё знаю :)

Флок один на файл

я не про это, епт, а про владельца

Уж я то про флок точно всё знаю :)

а ты точно всё знаешь? (с)

Всмысле что это не самафор чтоли ?

Что значит один на владельца

ох. ты меня гуглить заставляешь, дядя

```A process may only hold one type of lock (shared or exclusive) on a file. Subsequent flock() calls on an already locked file will convert an existing lock to the new lock mode.```

плюс, к исходной задаче flock вообще никаким боком, т.к никаких диапазонов внутри файла не поддерживает

Дапахонов нет. Верно. Ну и да. Там мысль была что один процесс не может несколько лочек делать на одном файле. Всё верно.

Но для синхронизации изменений в файле вполне достаточнр

не было такой мысли

при создании этого апи комиссия затупила и подмахнула реализацию, как есть, емнип

Но для синхронизации изменений в файле вполне достаточнр

только никакой тебе сериализации

и вообще, вложенный лок по бороде

Ну да

А чо. Как в эскулайте

И ничо. Живут же

более того. НЕЛЬЗЯ получить состояние лока файла по апи

это ваще пздц

более того. НЕЛЬЗЯ получить состояние лока файла по апи

Можно. Попробовать залочить

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

Получение состояния залочки это вобще бесполезная операция ибо оно может поменяться в следующую наносекунду

Можно. Попробовать залочить

бгг. я ж тебе говорю, что из одного процесса

Получение состояния залочки это вобще бесполезная операция ибо оно может поменяться в следующую наносекунду

ну это да, согласен, конечно

ERROR: S client not available

Можно. Попробовать залочить

lock1 - ok, lock2 - ok, unlock2 - приехали, лок снялся, т.к per inode/process

Что это за нах я прочитал ?

крч гогно этот ваш flock

Вложенных локов нет

Ксли ты сам залочил -- блять ну запомни это в переменной

а погли бы быть, с самым простым рефкаунтингом

а погли бы быть, с самым простым рефкаунтингом

Это называется семафор

И они есть в линупсе

но нет же, как протащили (ibm вроде), без рефкаунтинга, так и стандартизировали

Даже три штуки разных

Это называется семафор

семафоры про совсем другое

семафоры про совсем другое

Ровно то же. Кагбы рекурсивная залочка

А. Или тебе надо чтобы одни анлоком все локи очищать ?

Чо надо то

Ровно то же. Кагбы рекурсивная залочка

ну ладна :) как ты снимешь семафор в том де самом процессе, в котором выставил?

хотя бы в теории

без внешних прерываний

Блять. Ну апи там такое

вот ☝️

Не понял кейс

и все это гавнище решается одним полем в структурке лока и 2-мя строчками рефкаунтинга

Блять а чо надо то. Напиши более подробный кейс применения

Я всеравно не понял

* I wish world was prefect, but it's not (c) kernel code *

Блять а чо надо то. Напиши более подробный кейс применения

да забей

http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html

If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex maintains the concept of a lock count. When a thread successfully acquires a mutex for the first time, the lock count is set to one. Every time a thread relocks this mutex, the lock count is incremented by one. Each time the thread unlocks the mutex, the lock count is decremented by one. When the lock count reaches zero, the mutex becomes available for other threads to acquire. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error will be returned.

Это штоли ?

да, но без pthreads

А чо. Птхреадс мутекс можно сделать в шаропамяти в замеморимапленром файле

У мну есть пример. Когда экспериментировал

можно конечно