Android Binder interprocess Communication---Registering service components---starting binder thread pool

This article refers to "Android system source code scenario analysis", author Luo Shenyang

First, the test code:

~/android/external/binder/server

----FregServer.cpp

~/android/external/binder/common

----IFregService.cpp

----IFregService.h

~/android/external/binder/client

----FregClient.cpp

Binder Library (Libbinder) code:

~/android/frameworks/base/libs/binder

----BpBinder.cpp

----Parcel.cpp

----ProcessState.cpp

----Binder.cpp

----IInterface.cpp

----IPCThreadState.cpp

----IServiceManager.cpp

----Static.cpp

~/android/frameworks/base/include/binder

----Binder.h

----BpBinder.h

----IInterface.h

----IPCThreadState.h

----IServiceManager.h

----IBinder.h

----Parcel.h

----ProcessState.h

Drive Layer Code:

~/android//kernel/goldfish/drivers/staging/android

----BINDER.C

----Binder.h

Second, source code analysis

Continue on an Android binder interprocess communication---Register the service component---Send and process the Bc_reply return protocol http://blog.csdn.net/jltxgcy/article/details/ 26339313, after executing the waitForResponse function, refer to the Android Binder interprocess communication---Register the service component---client sends bc_transaction. You should return the Transact method of the Ipcthreadstate class, return the Transact function of the Bpbinder class, and finally return to the Bpservicemanager class AddService function. Finally, return to the main function of the Fregservice class, implemented as follows:

~/android/external/binder/server

----FregServer.cpp

int main (int argc, char** argv) {fregservice::instantiate (); Processstate::self ()->startthreadpool ();//start a binder thread pool ipcthreadstate::self ()->jointhreadpool ();// The main thread joins the thread pool return 0;}

first, the member function of the Processstate object of the current process Startthreadpool to start a binder thread pool, and then continue to invoke the Ipcthreadstate object's member function Jointhreadpool of the current thread, Joins the current thread to the previously initiated binder thread pool to wait and process the interprocess communication request from the client process.

The following is an analysis of the implementation of the member function Startthreadpool of the Processstate class, and the implementation of the member function Jointhreadpool of the Ipcthreadstate class is also analyzed during the analysis.

The Processstate class's member function Startthreadpool is implemented as follows:

~/android/frameworks/base/libs/binder

----ProcessState.cpp

void Processstate::startthreadpool () {    Automutex _l (mLock);    if (!mthreadpoolstarted) {//default        = False mthreadpoolstarted = true;//prevents its member function Spawnpooledthread from being repeatedly invoked to start the binder thread pool        Spawnpooledthread (True);}    }

The member variable mthreadpoolstarted of the current process's Processstate object is initialized to False when it starts a binder thread pool. The value of the internal member variable mthreadpoolstarted is set to true to prevent its member function Spawnpooledthread from being repeatedly invoked to start the binder thread pool. The Spawnpooledthread function is implemented as follows:

~/android/frameworks/base/libs/binder

----ProcessState.cpp

void Processstate::spawnpooledthread (bool ismain) {    if (mthreadpoolstarted) {        int32_t s = android_atomic_add (1 , &mthreadpoolseq);        Char buf[32];        sprintf (buf, "Binder Thread #%d", s);        LOGV ("Spawning new pooled thread, name=%s\n", buf);        sp<thread> t = new Poolthread (ismain);//ismain is true        t->run (BUF);//Start a new thread    }}

Create a Poolthread object T, call its member function run to start a new thread.

The Poolthread class inherits the threading class thread and overrides its thread entry member function Threadloop, so when a thread corresponding to a Poolthread object T is started, its member function Threadloop is called. The implementation is as follows:

~/android/frameworks/base/libs/binder

----ProcessState.cpp

Class Poolthread:public Thread{public:    poolthread (bool ismain)        : Mismain (Ismain)//ismain is true    {    }    protected:    virtual bool Threadloop ()    {        ipcthreadstate::self ()->jointhreadpool (mismain);// Ismain true to        return false;    }        const bool Mismain;};

The member function Jointhreadpool of the Ipcthreadstate class is called the same as the main thread. The implementation is as follows:

~/android/frameworks/base/libs/binder

----IPCThreadState.cpp

void Ipcthreadstate::jointhreadpool (bool Ismain)//default value is true{... mout.writeint32 (ismain?    Bc_enter_looper:bc_register_looper);//ismain for true,bc_enter_looper ... status_t result;                do {int32_t cmd;            .... result = Talkwithdriver ();//registers itself in the binder thread pool, and a wireless loop waits for interprocess communication requests if (result >= no_error) {            size_t in = Min.dataavail ();            if (in < sizeof (int32_t)) continue;            cmd = Min.readint32 (); ... result = ExecuteCommand (cmd);//processing inter-process communication request} ... if (result = = Timed_ou        T &&!ismain) {//Always false, because Ismain is a true break;    }} while (Result! =-econnrefused && Result! =-EBADF); ... mout.writeint32 (bc_exit_looper);//exit Binder thread pool Talkwithdriver (false);} 

The parameter ismain is a default parameter, and its default value is true. From the previous call procedure, it is known whether the main thread of the fregserver process, or the threads that the fregserver process has just created, are active (Ismain to TRUE) requests to join the binder thread pool, That is, they are not added to the binder thread pool due to binder driver request creation.

The life cycle of a binder thread can be divided into three phases:

The first stage is to register yourself in the binder thread pool;

The second phase is a wireless loop that continuously waits for and processes inter-process communication requests;
The third stage is to exit the binder thread pool.

The result of the final execution is that Fregserver has two threads, and sleep waits for inter-process communication data to arrive.