Расширение функционала программы на Си через другие языки

Ничто не мешает реализовать первый вариант, а потом написать плагин, который будет по сути прослойкой между API и пайпами. Соответственно, плагин на питоне будет выглядеть как плагин на питоне, использующий stdin/stdout и шаблонная so-библиотека (абсолютно одинаковая, меняется только имя файла, который нужно запустить и чей стандартный ввод-вывод перехватывать), которая только и делает, что транслирует вызовы API в пайп, предварительно запустив питонью программу.

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

neovim выбрали msgpack-rpc для общения с дополнениями. Я пока склоняюсь к mqtt. С последним, благодаря mosquitto-client, «дополнения» можно писать наколенке (на баше, по крону вызывается mosquitto-client с нужными опциями, плюет данными в брокер, а брокер уже сам рассылает эти данные всем подписавшимся. Соответственно, задача упращается в разы)

http://www.troubleshooters.com/codecorn/lua/lua_c_calls_lua.htm

Не разбираюсь в теме. Но может тебе нужно что-то такое?

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

Не совсем понятен ход твоих мыслей. Если ты пишешь плагин на сишке или любом другом языке, умеющем в C ABI, то получаешь so-шку, которую потом грузишь через so = dlopen() и общаешься примерно так:

struct API {
    int (*func1)(void);
    double (*func2)(const char *s);
} api = { ... };

struct PluginAPI {
    void *instance_data;
    struct API *api;
    void (*close)(struct PluginAPI *plugin);
    void (*process_event)(struct PluginAPI *plugin, const char *event);
};

void *so = dlopen("/path/to/plugin.so", 0);
struct PluginAPI *plugin1 = dlsym(so, "plugin_new")(&api);
plugin1->process_event(plugin1, "event_name");
// ...
plugin1->close(plugin1);
dlclose(so);

Для некомпилируемых языков просто будет одна so-шка для всего языка, которая будет бриджить API в язык и обратно, экспортируя его символы в соответствии с как там принято. Точно также PluginAPI будет замаплен на функции в скрипте. Единственное внешнее отличие — придется передавать имя скрипта в plugin_new:

dlsym(so, "plugin_new")(&api, script_path);

можно ли как-то таки скомпоновать хотя бы питоньий код в динамическую библиотеку

Можно, но зачем? Хочешь обязать «одминов» статически компилировать питон вместе со скриптом на каждый скрипт? Пусть пишут свои settings.lua, proces1.pl и obrabotka_dannyx.py где-нибудь в /usr/local/share/<daemon_name>/scripts и все.

Реализовывать оба интерфейса возможности нет

Не вижу причин. Если ты сделаешь бридж в скриптовую среду, то кто-нибудь за вечер склепает на ней модуль с posix.popen и начнет юзать его как типо-cgi-прокси. Вот необходимости такой и правда нет.

2 Lua и немного страданий вне очереди.

можно ли как-то таки скомпоновать хотя бы питоньий код в динамическую библиотеку?

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

Тоже думал об этом, вариант неплохой.

Спасибо за либу, сейчас почитаю, возможно, и не придется велосипедить)

Для некомпилируемых языков просто будет одна so-шка для всего языка, которая будет бриджить API в язык и обратно, экспортируя его символы в соответствии с как там принято.

А можно поподнобнее об этом? Не для задачи, просто интересно.

на мой взгляд у вас идея шиворот-навыворот.

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

удобнее тем, что:

• 100% что существуют языки более высокого уровня подходящие для вашей задачи
• ядро проще модифицировать если оно на дин.языке высокого уровня
• API расширений/модулей стабилен и поддерживается не вами
• (вытекает из 1) можно найти готовые/годные модули и не писать самим

Чем меньше оверхеда и затрат - тем лучше. (пишу системный демон с довольно высокой частотой пробуждения)

Инфа 99% что питона для всего хватит полностью. Но деталей, как всегда, автор рассказать не пожелает.

Собственно, я вижу два варианта устройства расширений:
1. Динамические библиотеки - подгрузка через dlopen, короче канон расширений плагинами.
2. Что-то вроде подхода CGI - единый интерфейс обмена через переменные окружения, stdin/stdout

Через POSIX Shared Memory еще можно

Все обожают луа, но в качестве языка сткиптов все-равно берут js. Прям загадка

Либо сразу js интерпретатор с API, либо плагины, а плагин уже может реализовать все что тебе нравится и сам встроить js.

зы lua фтопку.

lua - говно. точнее не сам язык говно, а интерпретаторы. Насколько я понял выбирать особо не из чего. lua, luajit, llvm-lua. Вроде бы единственный «юзабельный» - luajit, но он убог из-за дурацкого ограничения «на 64х битной системе память для lua интерпретатора должна выделяться только в первых двух гигабайтах адресного пространства».

А потом имеем вот такие костыли:
http://hacksoflife.blogspot.de/2012/12/integrating-luajit-with-x-plane-64-bit...

зы и да, два года спустя воз и ныне там.

lua - говно. точнее не сам язык говно, а интерпретаторы.

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

зыж llvm-lua вообще недоразумение

тыибанись. нахер тебе джит?

Чтобы оно не тормозило?
http://luajit.org/performance_x86.html

точнее не сам язык говно, а интерпретаторы

Ситуация с точностью наоборот. У луа есть референсный интерпретатор на ANSI C с красивым стандартным C API, для которого уже написана куча биндингов.

А js-интерпретаторов масса, причем популярные явно избыточны для встраивания и написаны на плюсах. А такого, чтобы имел C API и готовые биндинги - нету. v7 хорош, но вложено в него явно меньше человеко-часов, чем в луа

Чтобы оно не тормозило?

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

Там 5.1 это значит раз. 5.1 это вообще другой язык по сравнению с 5.3 хотя бы потому что в 5.3 есть честные целочисленные и битовые операции, а не через double как в 5.1.

А в целом lua не про это. луа про клей между нативщиной.

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

Т.е. тебя плюсы смущают? :)

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

А для чего его встраивают? Ты можешь гарантировать, что lua не станет узким местом в проекте?

Подробнее разве что реализация бриджа будет... Ну вот частичный пример для мерзкого ненужного Lua:

struct PluginAPI *
plugin_new(struct API *api, const char *path)
{
    struct PluginAPI *me = malloc(sizeof(*me));
    me->L = luaL_newstate(); // создаем стейт
    luaL_openlibs(me->L); // стандартные либы

    // registry.api = api
    lua_pushlightuserdata(me->L, api);
    lua_setfield(me->L, LUA_REGISTRYINDEX, "api");

    // globals.func2 = api.func2
    lua_pushcfunction(me->L, l_func2);
    lua_setglobal(me->L, "func2");

    if (luaL_dofile(me->L, path)) {
        // report error
        lua_pop(L, 1);
    }

    return me;
}

static struct API *
l_api(lua_State *L)
{
    lua_getfield(L, LUA_REGISTRYINDEX, "api")
    struct API *api = lua_touserdata(L, -1);
    return lua_pop(L, 1), api;
}

static int
l_func2(lua_State *L)
{
    const char *s = luaL_checkstring(L, 1);
    lua_pushnumber(L, l_api(L)->func2(s));
    return 1;
}

Теперь можно в скрипте говорить print(func2("qwe")). По аналогии можно обрабатывать события-вызовы из главного модуля, только нужно обертки написать C-to-Lua по типу l_func2 и засунуть их в PluginAPI. Как видишь, этот модуль универсальный для всего языка, только путь к скрипту разный (или один даже и тот же, можно несколько инстансов создавать). То же самое будет для питона, для перла (с мультиплисити), для лиспа, для жс.

Т.е. тебя плюсы смущают? :)

Ну попробуй интегрируй V8 в rust. Или напиши сишную либу для nodejs

А для чего его встраивают?

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

Бери первый вариант. Можно будет потом, если что, доставить таким образом поддержку питоньих скриптов. (или любых других, лишь бы сишное ABI умело)

А потом скриптиков внезапно становится несколько десятков и выполняться они должны десятки раз в секунду. А сволочи-пользователи начинают писать тяжеловесные скрипты. И тут вдруг начинаются тормоза.

Правильно, не стоит пользователям давать свободу - путь расширенияна си пишут, не такие резвые будут.

Количество скриптиков значения не имеет (все-равно большинство будет лежать мертвым грузом почти всегда), а вот частота - да. Если она измеряется в секундах - то референсный lua. А если чаще - то, наверное luajit. А лучше си)

путь расширенияна си пишут, не такие резвые будут.

тогда их нужно в отдельный процесс пихать, а иначе очень легко получишь segfault

Уж лучше luajit - ffi там шикарный.

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

Специально для таких целей изобретен Луа. Встраиваемый и быстрый. Питон тут сильно проиграет по производительности.

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