binder 双向通信时客户端没有joinThreadPool也能接收到服务端的请求

服务端之所以能够接收到客户端的请求，并能正确调用服务端进程中对应服务的onTransact方法，是因为服务端会通过joinThreadPool或者startThreadPool，在里面循环的等待客户端的请求并在接收到请求之后做对应的处理。
但是今天我在用C++写binder双向通信的代码时，发现，我客户端并没有调用joinThreadPool或者startThreadPool，也能接收到服务端的请求，而且能正确的调用对应的方法，这是为什么呢？理论上我客户端都没有在循环的等待服务端的数据并做处理，那这个是怎么调用到的呢？
我的代码实现是这样写的：
客户端：

service->registerCallBack(new BnCallBack());//1，先向服务端注册一个callback，即通过writeStrongBinder写入一个BBbinder对象	
service->say_hello();//2,远程调用服务端的方法

//3,如果接收到回调消息，则进行处理
status_t BnCallBack::onTransact(
    	uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
		{
		int ret;
		int32_t strict_policy = data.readInt32();
    	switch (code) {

        	case SUCESS_CMD: {
				int32_t code = data.readInt32();
            	onSucess(code);
            	return NO_ERROR;

服务端:

void BnHelloService::say_hello(void){
	int cnt = callback->onError();//回调客户端
	ALOGD("call say_hello : %d\n",cnt);
}

为了搞清楚客户端是如何调用到对应的方法，打印了一下调用栈

 onSucess:: #00 pc 00003635  /system/bin/test_client
04-26 10:18:46.968 10131 10131 D onSucess:: #01 pc 000035d1  /system/bin/test_client
04-26 10:18:46.968 10131 10131 D onSucess:: #02 pc 000359df  /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+70)
04-26 10:18:46.968 10131 10131 D onSucess:: #03 pc 0003d16d  /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi+684)
04-26 10:18:46.968 10131 10131 D onSucess:: #04 pc 0003d635  /system/lib/libbinder.so (_ZN7android14IPCThreadState15waitForResponseEPNS_6ParcelEPi+224)
04-26 10:18:46.968 10131 10131 D onSucess:: #05 pc 00036589  /system/lib/libbinder.so (_ZN7android8BpBinder8transactEjRKNS_6ParcelEPS1_j+36)
04-26 10:18:46.968 10131 10131 D onSucess:: #06 pc 0000331f  /system/bin/test_client
04-26 10:18:46.968 10131 10131 D onSucess:: #07 pc 00002ded  /system/bin/test_client
04-26 10:18:46.968 10131 10131 D onSucess:: #08 pc 00016c61  /system/lib/libc.so (__libc_init+48)

可以看出是在BpBinder的transact方法中开始调用的，在transact方法中又调用waitForResponse方法。
原来在客户端远程调用say_hello方法后，就会通过waitForResponse等待服务端返回数据，而刚好，我回调的方法又是写在say_hello方法中，这就导致服务端在该方法内发出BC_TRANSACTION，那在客户端就会收到BR_TRANSACTION,进而正确的调用到对应的方法。

总结
如果服务端是在客户端的远程调用方法内又回调给客户端，这时候还是由客户端主动发起请求，是不需要添加循环等待服务端的数据的。如果是在其它的地方，服务端需要主动的发送消息给客户端，这时候，客户端依旧需要通过joinThreadPool或者startThreadPool来处理服务端的请求。