Вопрос к программистам на C , Исходники ядра Linux

Цитата Ho Im @ 25.04.06, 09:21

Вы очень умно рассуждаете, но есть животрепещущий вопрос: кто-либо может подсказать библиотеку-фреймворк для написания асинхронно работающего сервера (то есть: главный цикл ловит события и передает коллбэкам, которые можно выстраивать в цепочки), короче, некий аналог питоновского Twisted (можно урезанный), только — ахтунг! — на чистейшем C?

А на С++ нельзя?

Низзя. Оченно желателен именно Си. А что плюсового можешь предложить?

Цитата Ho Im @ 25.04.06, 09:34

А что плюсового можешь предложить?

Если без многопоточности, то boost::signal в руки - и будут тебе "асинхронные" callback'и. Если же с применением многопоточности (схемы producer-consumer), то добавить сюда boost::thread + std::queue. Просто я слабо себе представляю - что такое "питоновский Twisted".

Цитата

А на С++ нельзя?

А надо?

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <syslog.h>
#include <string.h>
 
int main(int argc, char *argv[] )
{
/* Our process ID and Session ID */
pid_t pid, sid;
 
/* Fork off the parent process */
pid = fork();
if (pid < 0)
{
  printf("fail create child\n");
  exit(EXIT_FAILURE);
}
 
if (pid > 0)
{
  exit(EXIT_SUCCESS);
  prinf("able to creat child\n");
}
 
/* Change the file mode mask */
umask(0);
 
/* Open any logs here. Ho Im, can you add some code here? For ex. -- openlog(), etc... */
 
/* Create a new SID for the child process */
sid = setsid();
if (sid < 0)
{
  printf("able to create SID\n");
  /* Log the failure */
  exit(EXIT_FAILURE);
}
 
/* Change the current working directory, i.e. for CHROOT only. */
if ((chdir("/var/www/hoim_daemon")) < 0)
{
  /* Log the failure */
  exit(EXIT_FAILURE);
}
 
/* Close out the standard file descriptors. */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);
 
while( 1 )
{
/* Do something here... */
}
exit(EXIT_SUCCESS);
}

В данном случае это -- просто тупой демон. Теперь нам требуется добавить в него функционал. Какие, говоришь, тебе там функции нужны?

Собственно, чего делает Twisted.

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

В случае, если дергать слишком долго (например, надо обратиться в БД), отделяется тред, по окончании работы которого дергается коллбэк.

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

Задача программиста -- написать обрабатывающие события классы. Подход довольно специфичный, потому как заранее неизвестно, _когда_ что будет вызываться. Задача описывается почти что декларативным методом, хотя много чего довольно неплохо описывается как конечный автомат (Twisted, по сути, на них и рассчитан).

Подробности лежат на twistedmatrix.com.

На питоне писать хорошо, но потом приходит "зоказчег" (sic), и требует то закрытого кода, то легковесную реализацию.

Цитата Ho Im @ 25.04.06, 09:52

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

Как это хотелось бы, чтобы выглядело в коде?

Цитата Ho Im @ 25.04.06, 09:52

В случае, если дергать слишком долго (например, надо обратиться в БД), отделяется тред, по окончании работы которого дергается коллбэк.

Как определяется, что нужно запускать новый поток?

Цитата Ho Im @ 25.04.06, 09:52

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

В смысле?

Цитата

Организует тупого демона и дает ему в руки веревочки.

Почти сделано. Вторую часть надо доделать.

Цитата

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

По всей видимости, ставит на прослушку ряд сокетов и, если что-то пришло по сокету, то что-то делает? Неясна спецификация (что ждём и что делаем).

Цитата

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

Да полноте! Довольно будет спецификации -- какой порт слушаем, чего ждём из порта и что делать, в случае, если указанное событие наступило.
Правда, я бы предложил порождать поток при наступлении события. Т.е., в ряде случаев, будет работать не один поток, а несколько, но... Это будет необходимо для "развязки" между основным потоком исполнения и потоками реакций на события.

Давай спецификацию, отче...

Цитата

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

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

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

Мне спецификацию ждать, или сам напишешь?

Добавлено 25.04.06, 13:39
Ээээ... Прочитав документ по ссылке ржал долго... (eBook: "Object-Oriented Programming with ANSI-C," by Axel-Tobias Schreiner -> http://www.planetpdf.com/codecuts/pdfs/ooc.pdf)... А ты говоришь -- "расширяется стандарт... не расширяется стандарт..."

Добавлено 25.04.06, 13:56

Цитата

Ну и замечательно. При чем тут предмет спора?

Угу. Только в реальной жизни мне чуть-ли не навязывается мнение о том, что С -- отстой полнейший для "застрявших в 80-х".

Цитата

Сколько вариаций CRTL известно современной науке?

А Бог его знает...

Цитата

Но любая из них в первую очередь подчиняется стандарту ISO/IEK 14882. Приведенная абревиатура ни на какие мысли не наводит? Или одни международные стандарты стандартнее других?

Извини, это как-то соотносится с POSIX? Т.е., если я суну нос в 1003.Х, то там его найду, да?

Цитата

В данном случае - splint. А что я делаю не так, если у меня компилятор большинство косяков сам ловит и носом в них тычет? Безо всяких сплинтов, и другого подобного утиля?

Мой то же... Однако, зачем-то разработали splint & Valgrind и всё как-то пытаются портировать его под M$ и кучу других платформ. Зачем? Да затем, чтобы указать программисту на явные глупости в коде.

Цитата

Слабо понимаю, как стандарт POSIX связан с обсуждаемой темой.

Да ты что! А как быть с тем, что именно POSIX 1003.1x определяет что и как должно быть в системе в части безусловного базиса? Или, главное -- чтоб стандарт был, а вот что он описывает и на фиг нужен -- дело десятое?

Цитата

И какие стандарты de-jure ты имеешь ввиду?

Чуть выше.

Цитата

А где я предлагал такое?

Чуть ниже...

Цитата

Шад, ну как как... Также как и на С. :tong: :D :D :D Если ты берешься утверждать, что на С++ нельзя написать библиотеку, предоставляющую С-шный интерфейс своим клиентам, а также что в С++ нельзя использовать библиотеки с С-шным интерфейсом - ты заблуждаешься. Причины того, что обычно прикладное ПО предоставляет библиотеки с интерфейсом на С, а не на С++ я уже приводил.

И ещё чуть ниже...

Цитата

А где, позволь узнать, я предлагал писать библиотеку, изобретая при этом велосипед? Что-то я тебя недопонимаю. Я лишь написал о возможности написания как-либо библиотеки на С++, имеющей С-подобный интерфейс.

Был конкретный вопрос -- работа с СОМ-портами. В любой ОС (как ни странно, даже в WindoZE) есть функции по работе с ними. Зачем писать какую-то либу с С-подобным интерфейсом?

Цитата the_Shadow @ 25.04.06, 13:18

Угу. Только в реальной жизни мне чуть-ли не навязывается мнение о том, что С -- отстой полнейший для "застрявших в 80-х".

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

Цитата the_Shadow @ 25.04.06, 13:18

А Бог его знает...

А ты посчитай. Ради интереса. Одна - для gcc. Другая - для Intel С, третья - для MSVC, четвертая - для Borland, пятая - для MetroWorks, шестая - для lcc, седьмая для Comeau... Вообщем, список можно продолжать и продолжать. И у каждой из них (заметь) свои особенности. Так что ты там про STL то говорил?

Цитата the_Shadow @ 25.04.06, 13:18

Извини, это как-то соотносится с POSIX? Т.е., если я суну нос в 1003.Х, то там его найду, да?

А почему ты должен в стандарте на API операционной системы найти ссылки на библиотеки компиляторов под эту систему? См. ниже:

Цитата the_Shadow @ 25.04.06, 13:18

Да ты что! А как быть с тем, что именно POSIX 1003.1x определяет что и как должно быть в системе в части безусловного базиса? Или, главное -- чтоб стандарт был, а вот что он описывает и на фиг нужен -- дело десятое?

Шад, ты считаешь это ответом на вопрос

Цитата Flex Ferrum @ 25.04.06, 09:21

Слабо понимаю, как стандарт POSIX связан с обсуждаемой темой.

?
Ну не связаны эти понятия. Ну никаааак. Есть системное API. Есть зоопарк инструментальных средств, с помощью которых это API можно подергать. Это разные вещи. А у тебя получается так: "Шад, а почему оно зеленое?" "А потому что, Flex, оно мягкое".

Цитата the_Shadow @ 25.04.06, 13:18

Был конкретный вопрос -- работа с СОМ-портами. В любой ОС (как ни странно, даже в WindoZE) есть функции по работе с ними. Зачем писать какую-то либу с С-подобным интерфейсом?

Шад, слушай. Ответь честно - тебе вообще оппонент в дискуссии нужен? Мне кажется, что нет. Ты прекрасно можешь ставить вопросы, и сам же на них легко отвечаешь. Ибо на тот твой вопрос был дан вполне конкретный ответ:

Цитата

Также как и на С

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

Цитата

И у каждой из них (заметь) свои особенности. Так что ты там про STL то говорил?

А кто тебе мешает пользоваться одной реализацией, причём, не на основании анализа -- какая реализация луше, а на основании того, какой компиль и какие стандартные либы луше.
Кстати, это, вообще говоря, в большей степени не столько компилятора, сколько линкера и библиотек. Если совсем уточнять.

Цитата

Есть системное API. Есть зоопарк инструментальных средств, с помощью которых это API можно подергать.

Да ты чтоооо? Найди в приведённой заготовке демона несистемные API, зависящие от производителя какой-либо из версий компилятора|линкера под Linux? Или не соответствующие базисной спецификации, сиречь, POSIX? Навряд ли найдёшь. Уверяю тебя -- оно и под Solaris заведётся.

Цитата

А почему ты должен в стандарте на API операционной системы найти ссылки на библиотеки компиляторов под эту систему?

Ээээ... Flex'ушко, дорогой ты мой... Да где же у компилятора библиотеки??? По-моему, всё смешалось в доме Обломских... мимо проскакала одноногая курица...
Какая мне разница какой я либой пользуюсь, если компиль перегоняет мой код в объектник, а линкер потом к этому коду привязывает либы (в т.ч. и CRT)? В моём случае компиль фантазирует в весьма ограниченных пределах...

Цитата

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

Нет. Не проигнорировал. Заметь -- я просто сказал о том, что создавать в таком случае ни чего не нужно. Всё уже есть.
Flex, основная идеология С -- быть как можно ниже, но не до абсурда к основе системы, к недрам её реализации. Вот и всё... И не более того,

Да, такого я давно не видел.

1. Так кто-нибудь ответит ясно, почему нехорошо использовать С++ без исключений и RTTI в ядре? Из-за невозможности использовать STL? Извините, но ограничения на использование STL не больше, чем на CRT.

2. Чего вы докопались до выравнивания сегментов? Как это относится к качеству когда, генерируемого компилятором? Вы знаете устройство загрузчика исполняемых файлов в Windows? А может быть выравнивание по умолчанию уменьшает время запуска программы.

3. И что, у нас нету в ядре реализации стандартного сишного mallocа? Т. е. менеджер памяти отсутствует? У нас что, процессы могут писать куда угодно в памяти? И работа со swapом тоже в стандартной либе организована?

Сообщение отредактировано: Sanek - 25.04.06, 22:05

Цитата

Извините, но ограничения на использование STL не больше, чем на CRT.

8-/ Да? Правда? Ты скажи... как интересно...

Цитата

1. Чего вы докопались до выравнивания сегментов?
2. Как это относится к качеству когда, генерируемого компилятором?
3. Вы знаете устройство загрузчика исполняемых файлов в Windows?
4. А может быть выравнивание по умолчанию уменьшает время запуска программы.

1. А захотелось! Причина была проста -- Flex показывал как получить минимальный код (программы). Ему -- по приколу, мне -- то же.
2. К кодогенерации компилятором -- ни как. По-читай внимательнее -- там вопрос стоял по-иному.
3. Знаем, точнее знаем но не на все 100%. Посылаю... нет... не туда -- к сырцам одной из версий winDoze, которые есть в Сети. Не думаю, чтобы загрузчик одной версии оченно сильно отличался бы от другой. Причина проста -- если в любом случае мы работаем с COFF-файлом, то чего особенно вымудрять? Или это слабый аргумент?
4. Не факт и не всегда. На "скорость загрузки" исполняемых файлов влияет в первую голову... размер сего файла. В UNIX есть, кстати сказать, механизм UPX. Т.е., в ряде случаев дешевле загрузить файл в память (считав его с диска -- это самая длительная операция, т.к. "диск" -- устройство медленное) и, далее, распаковать его (в памяти), нежели грузить эти несколько мегабайт напрямую с диска. Во "вторую голову" играет роль скорость передачи управления твоему коду. Т.е., чем быстрее система передаст сформированному в памяти процессу управление, тем лучше. Здесь будет играть роль "выравнивание". Да. Но не такое, как первая причина. Так что, в ряде случаев (особенно в экспериментальных целях) этим временем можно пренебречь. Там есть ещё причина -- как именно собрано твоё ПО -- нужно ли будет использовать shared libs или всё в одном. Но это -- третья причина и, собственно, здесь она вообще не рассматривается.

Цитата

И что, у нас нету в ядре реализации стандартного сишного mallocа? Т. е. менеджер памяти отсутствует? У нас что, процессы могут писать куда угодно в памяти? И работа со swapом тоже в стандартной либе организована?

Полный LOOOOOL!!! Господи! Ну как именно "менеджер памяти" соотносится с вызовом "системной функции"?!? Блллл? ! А что первично, что вторично -- полюбопытствовать позволите? Или кто-то хочет рассказать, что "менеджер памяти" зависит от реализации malloc? Ээээ... Это правда? И при чём здесь то, как именно работает "менеджер памяти", если в нашем случае malloc -- не более чем интерфейс к нему? Юноша, это вещи из абсолютно разных категорий. То, что malloc использован при реализации функций работы менеджера памяти, во-все не означает того, что сам по себе malloc есть определяющая составляющая самого менеджера памяти. Или вы хотите меня клятвенно заверить, что malloc в Solaris = malloc из Linux или QNX???

Так... Бегом матчасть учить.

P.S.
Flex, потом продолжим -- сейчас занят сильно. Ээээ... Там же ещё swap нужно... Да. По-позже сделаю. Причём, клятвенно обещаю что без грязных трюков.

У malloc'а несколько реализаций. Он с ядром контактирует, но является приблудой из либца сам по себе. В темные века, когда _интенсивно_ пользующие malloc()/free() программы были редкостью, не в диковинку были различные реализации malloc'а (вспомним dmalloc, вошедший в новые версии glibc). Теперь очередь за реализациями dlopen(), хотя ядро как-бы умеет формат ELF.

Цитата Sanek @ 25.04.06, 22:01

И что, у нас нету в ядре реализации стандартного сишного mallocа? Т. е. менеджер памяти отсутствует? У нас что, процессы могут писать куда угодно в памяти? И работа со swapом тоже в стандартной либе организована?

Я плакалъ. Аффтар, пешы исчо!

Цитата

8-/ Да? Правда? Ты скажи... как интересно...

Есть какие-нибудь аргументы почему нет?

Цитата

3. Знаем, точнее знаем но не на все 100%. Посылаю... нет... не туда -- к сырцам одной из версий winDoze, которые есть в Сети. Не думаю, чтобы загрузчик одной версии оченно сильно отличался бы от другой. Причина проста -- если в любом случае мы работаем с COFF-файлом, то чего особенно вымудрять? Или это слабый аргумент?
4. Не факт и не всегда. На "скорость загрузки" исполняемых файлов влияет в первую голову... размер сего файла. В UNIX есть, кстати сказать, механизм UPX. Т.е., в ряде случаев дешевле загрузить файл в память (считав его с диска -- это самая длительная операция, т.к. "диск" -- устройство медленное) и, далее, распаковать его (в памяти), нежели грузить эти несколько мегабайт напрямую с диска. Во "вторую голову" играет роль скорость передачи управления твоему коду. Т.е., чем быстрее система передаст сформированному в памяти процессу управление, тем лучше. Здесь будет играть роль "выравнивание". Да. Но не такое, как первая причина. Так что, в ряде случаев (особенно в экспериментальных целях) этим временем можно пренебречь. Там есть ещё причина -- как именно собрано твоё ПО -- нужно ли будет использовать shared libs или всё в одном. Но это -- третья причина и, собственно, здесь она вообще не рассматривается.

На скорость загрузки исполняемых файлов их размер практически не влияет. Или вы хотитие сказать, что в "winDoze" при нормальных условиях исполняемый файл целиком считывается в оперативную память?

Цитата

Полный LOOOOOL!!! Господи! Ну как именно "менеджер памяти" соотносится с вызовом "системной функции"?!? Блллл? ! А что первично, что вторично -- полюбопытствовать позволите? Или кто-то хочет рассказать, что "менеджер памяти" зависит от реализации malloc? Ээээ... Это правда? И при чём здесь то, как именно работает "менеджер памяти", если в нашем случае malloc -- не более чем интерфейс к нему? Юноша, это вещи из абсолютно разных категорий. То, что malloc использован при реализации функций работы менеджера памяти, во-все не означает того, что сам по себе malloc есть определяющая составляющая самого менеджера памяти. Или вы хотите меня клятвенно заверить, что malloc в Solaris = malloc из Linux или QNX???

Да Flex Ferrum в общем то и говорил, что функции работы с памятью CRT импользуют syscallы для реализации своего функционала. На что ему сказали "Нет!". А теперь говорят то же самое

Цитата

Так... Бегом матчасть учить.

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