Мой первый pet-проект: процесс-менеджер synd3

[@Einherjar]

Хороший интерфейс у вас получился - наглядный и лаконичный, и глазу приятно

[@oxonomii]

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

[@sharptop]

Вставлю свои 5 копеек, поскольку тоже реализовывал в свое время свою утилиту по процессам ), правда не аналог top, а скорее аналог ps, ну и не на С, а на go.
Итак, что меня не устраивало в текущих утилитах типа ps/top и что мне часто нужно было видеть по работе - возможно вам это тоже будет полезно:
1) Нужно было видеть, сколько и какой процесс потребляет свопа, потому что часто с ним возникала проблема.
2) Нужно было понимание, процесс запущен на хосте или же в контейнере - во всех утилитах для этого приходится делать дополнительные действия, чтобы выяснить это.
3) Нужна фильтрация - показать только процессы, запущенные в контейнерах, показать процессы у которых потребление какого-то одного или нескольких ресурсов (например cpu и памяти или cpu и swap) больше определенных значений
4) желательно чтобы вывод команды можно было настраивать и чтобы этот вывод потом можно было бы использовать в пайпах для других программ

[@oxonomii]

Отличные идеи, спасибо большое!
Swap мы думали добавить в ближайшее время, так как это неотъемлемая часть нормального процесс менеджера, однако о контейнерах мы не задумывались — действительно полезный кейс.
Я подумаю, как можно реализовать определение процессов внутри контейнеров.
И фильтры — да, это одна из вещей, которую хочется добавить в TUI.

[@domix32]

что нас удивило

мы хотели,

А кого вас-то? Где я пропустил момент, когда статья внезапно стала от множественного лица?

VmRSS из /proc/[PID]/statm.

Я так понимаю про виртуальную память пока ещё ничего не выводилось. Про подумать о фичах

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

ncurses не является потокобезопасной библиотекой.

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

и сделали обновление экрана синхронным: сначала сбор данных, потом отрисовка.

Собственно с подгтовкой данных для рендеринга можно теперь унести рендеринг в отдельный поток. Глядишь ещё и двойную буфферизацию освоите.

Но ещё интереснее - попробовать самостоятельно навелосипедить свой ncurses, благо там нчиего сложного нет. Если конечно вас не интересует поддержка легаси кодировок и интернационализация.

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

Ну, и крайне советую включить хотя бы 17 стандарт и использовать std::string_view вместо голых char*. Заодно можно включить -Wall -Wextra, чтобы понимать, где могут быть косяки.

Вот так делать не стоит - разделяйте обработку данных и их отрисовку. В обще понятно откуда у вас могут быть проблемы с многопотоком. В идеале должен быть единственный вызов этой функции и общий флоу должен выглядеть как-то так

AppState state;
while(!state.should_close) {
  handle_input(state);
  if (state.should_close) {
      goodbye(state);
      break;
  }
  prepare_data(state);
  render(state);
}
// ну или ООП 
AppState state;
while (!state.should_close()) {
  state.handle_input();
  if (state.should_close()) {
    state.goodbye();
    break;
  }
  state.prepare_data();
  state.render();
}

Штуки типа таких стоит проворачивать через std::chrono, чтобы избегать проблем с какими-нибудь високосными секундами. Это, конечно, если вы не хотите дауншифтнуться до C.

Ну, а для такой магии изобрели enum.

[@Amareis]

Мы работали над проектом вдвоем

[@oxonomii]

Огромное спасибо за такой развёрнутый фидбек!
Да, нас двое — я и однокурсник, поэтому в тексте местами "мы".
Про ncurses согласен — это была одна из самых болезненных тем, особенно при попытке параллелить сбор данных и рендер.
Идея "навелосипедить свой ncurses" звучит интересно, вполне возможно, что в будущем мы это попробуем.
Так же, идею с подготовкой данных отдельно от отрисовки обязательно попробуем внедрить — звучит логично.
Отдельное спасибо за советы по std::string_view и статическим буферам, учтём при переходе на чистый С, когда "окончательно дауншифтнемся".

[@iamkisly]

В htop заглядывали ?

Несмотря на то что тут задача придумывалась под технологию, а не наоборот.. вставлю что для менеджера будет более уместен Data DD (какой-нибудь ECS), а не ООП

[@oxonomii]

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

[@inv2004]

Попробуйте https://github.com/inv2004/ttop/

+ там сохраняются исторические снепшоты

[@Tuxman]

Чтобы самому не изобретать TUI-велосипеды, и не связываться с ncurses, а писать на современном C++, предлагаю взять готовую библиотеку https://github.com/ArthurSonzogni/FTXUI