Glib学习笔记(2)

2.1 MainLoop

main loop是Glib中一个非常重要的部分，其主要用途类似于Windows的消息循环。所以它是一个循环，不停得从某个地方取得“消息”，然后派发到消息处理函数，交给他们处理。

从执行者角度看，派发到消息处理函数实际还是消息循环所在的线程调用对应的函数。

在Glib中，消息循环对应的就是这个mainLoop。消息队列没有对应物。但是消息的产地由GSource标示，例如一个文件描述符，一个socket都是某种source。Glib提供了GMainContext来管理这些source。而mainLoop只要管理Context即可管理很多source。

其实很简单，仔细比较下windows下的线程函数就可知道。Windows下的线程函数一般会循环等待一些事件，例如

while(TRUE)

{

WaitForMultiObjects(count,arry,...);

其中arry是一个事件数组。

}

仔细想想，mainLoop是上面那个while循环的对象封装，context是arry数组的对象封装，而arry里边的成员就是source的对象封装。

通过这种方式的对象封装，在不同线程里边直接使用mainLoop对象，或者切换context对象就可以做到非常方便简洁。

循环退出，必须有个事件处理中调用g_main_loop_quit才可以。

如果你能这么理解MainLoop的话，就非常容易从WIN-API转到GLib中去了。

实际上，MainLoop的整个系统比较精巧，涉及到定时源，空闲源，优先级等。

我看了下Glib的实行代码，内部对应WaitForMultiObjects的是poll函数。可想，如果有很多事件的话，由poll本身造成的效率损失将比较大。另外它是在一个线程中执行处理函数的，所以会影响后续事件的处理。

下面将详细讲述和比较。

1.迭代

其实就是强制调用一次WaitForMultiObjects以检查发生了什么事件。Glib对context分了好几种状态。

图 Context状态

状态只有context才有，想想和Wait函数的那个比较。待会再解释那几个状态以及对应函数的原型说明。

从这个图以及源代码看，一次iteration调用包括先prepare下，然后调用poll函数，然后调用check—>dispatch。具体干了什么，下面再说。其实就是讨论wait函数的内部实现

这些个状态的确定是需要调用对应源的函数来确定的。而源函数由GSourceFuncs来确定。

typedef struct {

gboolean (*prepare) (GSource *source,

gint *timeout_);

gboolean (*check) (GSource *source);

gboolean (*dispatch) (GSource *source,

GSourceFunc callback,

gpointer user_data);

void (*finalize) (GSource *source); /* Can be NULL */

/* For use by g_source_set_closure */

GSourceFunc closure_callback;

GSourceDummyMarshal closure_marshal; /* Really is of type GClosureMarshal */

} GSourceFuncs;

prepare函数：将调用每个source的这个函数以确定哪些已经准备好了，source在这些函数里边可以判断下自己的真正的源（比如socket）是否已经准备好，timeout是表示需要等待的超时时间。最终的超时时间将是所有源的最小时间。如果确定已经准备好了，则返回TRUE，表明后续就不用在poll中等待它了。

check函数：这个函数的存成，主要是prepare返回FALSE，而且poll也没等到，所以只能在Poll后再由程序自己去确定是否发生了啥时间。

dispatch函数：处理prepare或check函数返回TRUE的事件。这两个函数有一个返回TRUE就表明有东西要处理了。

应该查看代码确定下，是不是prepare返回TRUE的话，就不调用poll和check了。

经查，check只对非READY状态的source进行调用。

prepare本身没干什么，好像还是会调用poll。

最终调用dispatch的就是那些返回READY的句柄

2.2函数API

l main_loop相关函数，主线程有一个默认的context

l main_context相关函数，中断wait—g_main_context_wakeup

(1) context的所有权，只有线程得到context的所有权后，才能处理它。想想也是。

(2 )g_main_context_push_thread_default系列函数，干嘛使的？看了下实现，才知道每个线程都有一个私有数据队列，这个队列stack存的就是context。而g_main_context_default返回的是主线程的那个context（其实是一个全局变量的context。个人感觉一般不要操作这个mainloop。或者只由主线程去操作它。）

l 事件优先级define

l 空闲事件源，得先创建一个，然后插入到context中去。回调函数的返回值决定下次是否继续调用。

l 定时事件源。同上。

另外，关于source的创建及其使用，感觉怪怪的。只能attach，没有detach，而且只有destroy后不能再attach。why？

另外，g_source_new这个函数特别奇怪，返回的是GSource*，为何又要我传入GSource结构的大小？难度自己不知道吗？看了看实现，也没什么区别呀。或许可以从GSource中派生？

一个source里边含一个fd队列，所以new出来这个source对象实际是一个简单的封装，后续还是要把真正的fd加入到这个队列中去。

这么看来，如果要使用source干点活的话，还是得直接从I/O通道中创建source。

2.3 线程和线程池，异步队列

要在glib中使用线程，必须先调用g_thread_init来初始化线程库。

这个要求挺奇怪，里边肯定是有什么东西是全局的，所以要先初始化一下。

线程及同步结构没什么太多神奇的地方，一定是对POSIX同步结构进行了一下封装罢了。有些静态对象的使用，不需要初始化线程库也行。关键是用法要习惯。

线程池是一个有点奇怪的地方，主要是它的用法和参数上。

l 先创建一个线程池对象，里边会启动线程（可能）。叫任务池可能更好一点。

l 任务参数比较奇怪，有两个，一个是任务本身，另外一个是user数据。后来查看了下代码，通过g_thread_pool_push等加入的是任务，而用户数据则是在创建pool的时候传入的，所以对一个任务执行来说，有两个参数。其实里边就是一个list，把任务数据保存在list中罢了

异步队列，是一个比较实际的东西。原理很简单，有线程往里边加东西，另外有线程往里边取数据，这里围绕队列进行了同步处理。所以叫异步队列。

2.4 动态加载

动态加载需要包含gmodule.h，编译的时候也需要指定gmodule-2.0。

动态加载对这个路径分隔和模块后缀进行了宏定义，在不同平台下用一个宏即可。

有一个比较有意思的地方，在UNIX平台下，就是动态加载时候的CheckInitFunc和Unloadfunc。这两个函数是在加载动态库前和卸载前调用的最后一个函数。其实就是模仿Windows下的Dllmain函数。

l 内部处理经过勘察代码发现，CheckInitFunc是实际已经加载了，然后再调这个函数（所以模块必须实现一个叫g_module_check_init的函数）。这个典型的模仿DllMain

l UnLoadFunc是一样的道理。

G_MODULE_IMPORT和G_MODULE_EXPORT在Win下有意义。

2.5 内存分配和释放

这节的内容可能是经常要用到的。glib对一些C库函数进行了下封装吧应该。

g_malloc,g_malloc0,g_new,g_new0好像都没什么区别。

注意：一旦分配没成功，程序将直接exit。这点和库函数不一样。

晕，如果运行时候，出现这种问题也够可以的了。

2.6 I/O通道

分出来一个GIOChannel结构。实际代表一个FD，但是和source不太一样，source是事件意义上的源，而IO则是对FD的封装，这两个还是有本质区别的。

GIOChannel可以转换成一个source，也可以加入到context中，但只能是默认的全局context。

g_io_add_watcher,这个函数照实奇怪，为何不把context指针传进去啊，这样我就能加入到我想加入的context中去了。其实内部就是调用g_source_attach。非常奇怪。