Dianne, Thanks:-)
I add some log, and make sure
BR_SPAWN_LOOPER
cause all the spawn of second and later "Binder Thread"(which isMain
is false) display by "ps -p -t"
Seems BR_SPAWN_LOOPER is created in binder driver:
in kernel/include/linux/binder.h
I found following comments:
BR_SPAWN_LOOPER = _IO('r', 13),
/*
* No parameters. The driver has determined that a process has no
* threads waiting to service incomming transactions. When a process
* receives this command, it must spawn a new service thread and
* register it via bcENTER_LOOPER.
*/
I guess
"The driver has determined that a process has no threads waiting to
service incomming transactions"
means old "Binder Thread" can't be used, then the driver think this
process has no thread "waiting to service incomming transactions"
Then it want that process to create a new "Binder Thread".
Is there something wrong with my though?
Thanks&BstRgds
gan
On Jan 4, 4:52 pm, "Dianne Hackborn" <[email protected]> wrote:
> Yeah the only difference is that when the flag is set we don't allow that
> thread to exit like a normal thread pool thread (created for that purpose),
> since exiting the main thread of the process is not desirable. :)
>
>
>
>
>
> On Sun, Jan 4, 2009 at 12:20 AM, gan <[email protected]> wrote:
>
> > Hi, Dianne: Thanks!
>
> > This question sent is because I set a log at
> > ProcessState::spawnPooledThread(bool isMain)
> > Found only the first calling of this API, "isMain" is true;
>
> > I found this flag only be used at following case in
> > IPCThreadState::joinThreadPool:
> > if(result == TIMED_OUT && !isMain) {
> > break;
> > }
>
> > It is true that the different of them(isMain is true or false) is
> > small,
>
> > From the log:
> > ProcessState::spawnPooledThread(false)
> > is called(from the log, only first calling of this API within one
> > process, isMain is true, later, it would always be false),
>
> > I guess it is called at IPCThreadState::executeCommand:
> > case BR_SPAWN_LOOPER:
> > mProcess->spawnPooledThread(false);
> > break;
>
> > So I not sure in what scenario BR_SPAWN_LOOPER is used?
>
> > Thanks&BstRgds
> > gan
>
> > On Jan 4, 3:27 pm, "Dianne Hackborn" <[email protected]> wrote:
> > > I don't know what you mean by a "NONEMain Binder Thread," but each
> > process
> > > using the Binder will have multiple threads running in a thread pool to
> > > process incoming transactions and other work.
>
> > > Also there is no strong rule about the main thread ending up in the
> > thread
> > > pool (and nothing really special about that thread if it does go into the
> > > thread pool vs. any of the other spawned threads); in fact for normal app
> > > processes the main thread sits in the Java Looper class processing the
> > main
> > > message queue of the process.
>
> > > The system process is a little different, in that I believe the main
> > thread
> > > gets put into the binder thread pool, and another thread is created and
> > runs
> > > what serves as the main message queue/loop of the process, but it is
> > really
> > > only done this way due to convenience of implementation.
>
> > > On Sat, Jan 3, 2009 at 11:08 PM, gan <[email protected]> wrote:
>
> > > > Hi:
>
> > > > When I use "ps -p -t" to get the process and thread information, I
> > > > ofter found many "Binder Thread" belong to one Process.
>
> > > > My understanding is:
> > > > Only one "Binder Thread" is the "main Binder Thread" of that process.
> > > > It would be blocked in ioctl used for "waiting to read". (later to
> > > > execute some command by "BnXXXX::onTransact" according to read
> > > > contents. )
> > > > And it would be wake up by ioctl "writing" invoked by another
> > > > process's BpBinder::transact.
>
> > > > I found
> > > > /*spawn a new thread if we leave this out */
> > > > at the end of binder_thread_read.
>
> > > > My question is:
> > > > What the "NONEMain Binder Thread" used for?
> > > > Why new thread spawned?
> > > > What is it's relationship with old "main binder thread"?
>
> > > > Thanks&BstRgds
> > > > gan
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > [email protected]
>
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support. All such questions should be posted on public
> > > forums, where I and others can see and answer them.
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-framework?hl=en
-~----------~----~----~----~------~----~------~--~---
