Блог

Я пишу одно простое серверное и клиентское приложение, которое использует сокет для связи. На стороне клиента я создал GIOChannel для прослушивания событий сокета, таких как чтение, запись, исключение и т. Д. Клиент предоставляет некоторые асинхронные API.

Я написал один пример приложения для тестирования моего кода, который создает g_main_loop и создает один GIOChannel для событий клавиатуры.

 mainloop = g_main_loop_new(NULL, FALSE);
channel = g_io_channel_unix_new(0);
g_test_io_watch_id = g_io_add_watch(channel, (GIOCondition)(G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL), test_thread, NULL);
g_main_loop_run(mainloop);  
  

Он работает нормально, если я не зацикливаю или не блокирую основной поток в функции обратного вызова test_thread . Например, когда я вызываю любой асинхронный API клиента, я на некоторое время помещаю в спящий режим свой пример программы и ожидаю асинхронного сообщения от сервера к моменту пробуждения основного потока. Но этого не происходит, клиентский сокет получает событие чтения для чтения асинхронного сообщения с сервера только после возврата основного потока, который вызвал API.

Из этого я узнал как события keyboad, так и события сокетов, зарегистрированные для одного и того же контекста по умолчанию, и они не могут быть уведомлены основным диспетчером событий за одно и то же время.

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

Я нашел несколько API-интерфейсов через документы GNome, которые предназначены для добавления GIOChannel только для контекста по умолчанию. Я должен добавить GIOChannel, созданный для чтения сокета, в другой контекст.

Может кто-нибудь подсказать мне, как это сделать, или есть какой-нибудь лучший вариант для асинхронной обработки чтения сокетов с использованием GLIB.

Спасибо.