Не уверен, что понимаю именно то, чего не понимаете вы, но, возможно, это часть проблемы. ;-) Так что я буду стараться изо всех сил, и вы дайте мне знать, близко это или нет.
pantheios_fe_getProcessIdentity()
вызывается один раз при инициализации Pantheios. Вам нужно вернуть строку, которая идентифицирует процесс. (На самом деле он идентифицирует блок ссылок; термин, определенный в Imperfect C++, написанном создателем Pantheios, Мэтью Уилсон, что означает область имен ссылок, т. е. исполняемый программный модуль или модуль динамической библиотеки.)
pantheios_fe_isSeverityLogged()
вызывается всякий раз, когда оператор журнала выполняется в коде приложения. Он возвращает ненулевое значение, чтобы указать, что оператор должен быть обработан и отправлен на выход (через серверную часть). Если он возвращает ноль, обработки не происходит. FWIU, это главная причина, почему Pantheios такой быстрый.
pantheios_be_logEntry()
вызывается всякий раз, когда оператор журнала должен быть отправлен для вывода, когда pantheios_fe_isSeverityLogged()
вернул ненулевое значение и Ядро Pantheios обработало оператор (сформировав все аргументы в вашем коде в одну строку). Он отправляет строку оператора туда, куда она должна идти. Например, серверная часть be.fprintf выводит его на консоль с помощью fprint()
.
Как только вы вникнете в эти аспекты, вторая часть вашего вопроса станет интересной. Когда ваш внешний и внутренний интерфейсы инициализированы, они создают некоторый контекст (например, объект C++), который удерживает для них ядро Pantheios, и возвращает их каждый раз, когда оно вызывает функцию внешнего/заднего интерфейса API. Когда вы настраиваете оба, вы можете заставить их общаться через какой-то общий контекст, о котором они оба знают, но о котором ядро Pantheios не знает (и не должно) знать, за исключением непрозрачного дескриптора (void*
) для него.
ХТН
person
dcw
schedule
02.10.2009