Здравствуйте, cyberzlodey, Вы писали:

C>libaoc
C> Запилил на досуге простую библиотечку на мотив паттерна Active object на голом С. Какие комментарии по коду, архитектуре, стилю программирования? Буду рад конструктивному фидбеку. Спасибо.

взять готовую многопоточность из tiny threads. тогда получится тонкая надстройка над ним вместо дублирования его кода

Здравствуйте, niXman, Вы писали:

X>библиотека имеет переменную в глобальном контексте, в которую сохраняется errno.

Никогда не давай таких советов.


X>и, соответственно, библиотека предоставляет функцию для получения этого errno, типа: 'int active_errno(active_t*)'

Бредовый дизайн, не в духе С, а в духе "поколения next", за которыми приходится постоянно подчищать.

Здравствуйте, niXman, Вы писали:

X>т.е. в идеальном случае, код использования этой библиотеки должен быть таким:
X>

X>active_t *a = 0;
X>int ec = active_new(&a);
X>if ( ec ) {
X>   printf(stderr, "initialization error, errno=%d\n", ec);
X>   return ec;
X>}

Не должен. Этот подход не позволит воспользоваться некоей уже имеющейся прикладной инфраструктурой вокруг errno.

Вот классика жанра:

sockfd = socket(AF_INET, SOCK_STREAM, 0);

if (sockfd == INVALID_SOCKET) {
  notifyError("ERROR opening socket");
  return;
}

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


X>я пытаюсь обратить твое внимание на нелогичности.

Ты пытаешься задурить голову непонятно чем. Ты даже не обосновал, ЗАЧЕМ ты требуешь именно такой интерфейс. Вот с какой радости?

Здравствуйте, cyberzlodey, Вы писали:

X>>кстати, если твоя библиотека сессионная — то у каждой сессии может быть свой errno. значит сигнатура должна быть такой: 'int aoc_errno(active_t*)'

C>Да, active_t объектов может быть множество, соответственно обработка ошибок должна привязываться к конкретному объекту. Спасибо за мысль, так и сделаю.

Не слушай бредовых советов. Обработка ошибок должна привязываться к потоку исполнения, а не к объекту. Где для общего случая гарантия, что различные действия над объектом не будут вызваны из различных потоков? Даже если ты сериализуешь доступ к объекту, то после отпускания мьютекса у тебя не может быть никаких предположений о состоянии объекта и о состоянии его "флага ошибки". Поэтому, нужно пользовать только встроенный errno, который привязан к текущему потоку.

Кароч, всё то, что тебе советует "коллега" — это самые вредные советы из виденных мною на этом сайте. Полный П, как грится. ))

вы забыли отметить, что это всего лишь ваше мнение, одно из многих

Здравствуйте, niXman, Вы писали:

X>вы забыли отметить, что это всего лишь ваше мнение, одно из многих

Это не "мнение", это железное правило, принятое на сегодня везде в реально работающих АПИ, потому что альтернативные решения ошибочны. Моё мнение тут не при чем, "альтернативные" системы, действительно, работают с ошибками, вызванными банальными гонками, т.е. чаще всего банально писаны неопытными разработчиками.

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