> Это детект того, что вызовы завершились.тут я с Вами не соглашусь - тут и анализ завершения и анализ наличия ошибки (насколько я понимаю расчёт был на то, что retrieved_uid и retrieved_pid никогда, при нормальном завершении, не могут быть равными 0 - pid процесса и uid пользователя (хотя последний для пользователя root таки будет равным 0))
> Мне, кстати, интересно... Вот смотри, если первый завершившийся асинхронный вызов вернёт
> ошибку, то цикл вылетит из-за этой ошибки, так? А возвращаемое значение
> второго вызова так и останется необработанным? Так? И к чему это
> может привести в случае с дубасом? Глянь, data лежит на стеке,
> если сделать return после обработки первого вызова, то где-то там в
> недрах клиентского кода дубаса останется указатель на data, и дубас что-то
> запишет туда, как только появятся данные и будет сделан следующий вызов
> g_main_context_iteration. Или дубас гарантирует, что оба вызова будут обработаны в течение
> одного g_main_context_iteration?
по g_main_context_iteration() ничего сказать не могу - не специалист по glib, а могу только предполагать (см ниже.).
По поводу данных - там выше есть функция on_retrieved_unix_uid_pid() которая является callback-ом и которой передаётся указатель на эту data. Судя по всему сам указатель data в недрах dbus-а используется только для того, чтобы передать его callback-у, который там всё что надо будет заполнит. g_main_context_iteration() вызывает по одному callback-у (делает какой-то single iteration судя по документации), а т.к. потом (при наличии ошибки или при завершении одного из callback-ов), прекращает свой цикл, то попортить стек ему не удастся - второй callback вызвать будет некому. Возможно второе значение сбросится при удалении контекста в g_main_context_pop_thread_default(). Думаю, что там не всё так плохо, как могло-бы показаться на первый взгляд.
