SensorManager file descriptor shared?

by Huaka鈥榠 Po » Wed, 01 Apr 2009 23:11:05 GMT


Sponsored Links
 Hi all,
is the file descriptor in SensorManager.java global to all threads?

In setting up the event dispatch thread for sensor events, there is a
call
ParcelFileDescriptor fd = service.getDataChanel();
getDataChanel() eventually winds up calling open_data_source in the
sensor framework, which returns an open Linux fd.  Then the code
instantiates a new thread with a SensorThreadRunnable, part of which
is here:

private class SensorThreadRunnable implements Runnable {
  private ParcelFileDescriptor mSensorDataFd;
  SensorThreadRunnable(ParcelFileDescriptor fd) {
    mSensorDataFd = fd;
  }
...

The run() method of SensorThreadRunnable later closes mSensorDataFd.
Does that close the original fd returned by getDataChanel?  (i.e. is
the fd the same one in both threads, or are the semantics more like dup
() because of the Parcel stuff?)

Thanks,
Hod
--~--~---------~--~----~------------~-------~--~----~



SensorManager file descriptor shared?

by Dianne Hackborn » Wed, 01 Apr 2009 23:14:32 GMT


 Hi, you should probably post this on android-porting where I believe the
engineer who works on it posts.

If it helps, the call to the remote service causes a dup of the fd at that
point, so the client would only close the fd it received, not globally close
it for all processes.






-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

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.

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


SensorManager file descriptor shared?

by Huaka鈥榠 Po » Wed, 01 Apr 2009 23:23:59 GMT


 Thanks.
--~--~---------~--~----~------------~-------~--~----~



SensorManager file descriptor shared?

by Huaka鈥榠 Po » Wed, 01 Apr 2009 23:26:12 GMT


 (reposting from android-framework)
Hi all,
is the file descriptor in SensorManager.java global to all threads?

In setting up the event dispatch thread for sensor events, there is a
call
ParcelFileDescriptor fd = service.getDataChanel();
getDataChanel() eventually winds up calling open_data_source in the
sensor framework, which returns an open Linux fd.  Then the code
instantiates a new thread with a SensorThreadRunnable, part of which
is here:

private class SensorThreadRunnable implements Runnable {
  private ParcelFileDescriptor mSensorDataFd;
  SensorThreadRunnable(ParcelFileDescriptor fd) {
    mSensorDataFd = fd;
  }
...

The run() method of SensorThreadRunnable later closes mSensorDataFd.
Does that close the original fd returned by getDataChanel?  (i.e. is
the fd the same one in both threads, or are the semantics more like
dup
() because of the Parcel stuff?)

Thanks,
Hod
--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---



SensorManager file descriptor shared?

by pixelflinger » Thu, 02 Apr 2009 07:44:59 GMT


 Hi,

I'm not completely sure about what you're asking, so I'll do my best
to answer :-)

There is only one thread per process handling the events. Note that
there should only be one instance of SensorManager as well (it's a
singleton).

It's therefore not possible to have more than one thread per process
using the low-level sensor api from Java.


Now to answer your question literally, yes, the filedescriptor is the
same in both threads, therefore it gets closed when the thread
returns. But notice that getDataChanel() is called again when the
thread is re-started.

getDataChanel() gives ownership of the fd to the caller (conceptually
it does a "dup" before returning it).

Hope this helps.

Mathias




--~--~---------~--~----~------------~-------~--~----~



SensorManager file descriptor shared?

by pixelflinger » Thu, 02 Apr 2009 15:11:10 GMT


 There is only one thread per process handling the events. Note that
there should only be one instance of SensorManager as well (it's a
singleton).

It's therefore not possible to have more than one thread per process
using the low-level sensor api from Java.

Mathias





--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---



SensorManager file descriptor shared?

by Huaka鈥榠 Po » Fri, 03 Apr 2009 00:49:21 GMT


 I was guessing that was the case.  Thanks for the confirmation.  But
because the original fd returned by getDataChanel is used to create an
instance of  ParcelFileDescriptor (mSensorDataFd) before the event
handling thread is spawned, does anything happen behind the scenes to
make the descriptor local to that thread?  I'm asking both because in
sensors.h there's a comment 'The caller takes ownership of this fd.
This is intended to be passed cross processes.' (referring to
open_data_source) and because if the descriptor isn't made thread-
local by the Parcel code, I don't see why one would use a
ParcelFileDescriptor instance in the first place.

Further, the event handler thread closes mSensorDataFd.  The event
handler thread dies every time there are no more listeners.
Registering a new listener would then cause a new handler thread to
get spawned.  That will call getDataChanel again.  So the really I'm
asking whether getDataChanel has to open the device again, or whether
it can just open it once over the life of the SensorManager process?




--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---



SensorManager file descriptor shared?

by David Turner » Fri, 03 Apr 2009 06:33:14 GMT


 As far as I know, file descriptors are local to processes and inherently
shared by all threads in the same process







--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---



SensorManager file descriptor shared?

by Huaka鈥榠 Po » Tue, 14 Apr 2009 23:02:30 GMT


 Thanks.  These replies and some more digging on my own helped me
figure out what I needed.  Probably the most critical point I didn't
realize at first was that getDataChanel does some IPC stuff under the
covers to get a descriptor sent across process boundaries.  (I
originally thought everything was happening in a single process.)  For
anyone else running in to this, the fd returned by open_data_source
gets fed back from the sensor service to the requesting process.  Then
sensor service closes it for the system_server process.  The fd in the
receiving process is global to the process, so any thread closing it
closes it for all.




--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Still searching for HOME screen, and more question about ActivityManager

I've asked "how to detect home screen" before. I'm still searching...

I noticed when I press "home" button on Android emulator, I got this
statement in catlog:

INFO/ActivityManager(584):
 Starting activity: Intent { action=android.intent.action.MAIN
categories={android.intent.category.HOME} flags=0x10200000 comp=
{com.android.launcher/com.android.launcher.Launcher} }

so I went to ActivityManager to see if I can find a clue there. Here
is my findings:

1. I can not instantiate ActivityManager because it's constructor is
not public, and it's not a singleton
2. it has a function called: getRunningAppProcesses sounds promising
-- would it give me all the running processes?
3. since I can not instantiate ActivityManager I tried to use one of
the derived class: RunningAppProcesseInfo to see if I can use it's
parent methods: getRunningAppProcesses. Nope.

Am I on the right track or totally lost?

Thanks,

Sherry

--~--~---------~--~----~------------~-------~--~----~

2. Android update deleted

I stupidly deleted an Android update from my Notifications window on
my T-Mobile G1 last night.  T-Mobile can't help me re-send it.  Does
anyone know how I can get it?

Thanks!

--~--~---------~--~----~------------~-------~--~----~

3. How to query all phone numbers of all Contacts in the Database?

4. INDEX 2...INDEX 2...INDEX 2...

5. Question about using TextView

6. MapView Draggable Objects

7. Is MS Exchange really coming for us?