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. Is it possible to install Android on PlaySation 3

I was wondering if anyone knows if it is possible to Install Android
on PS3.  And if so how?

Thanks

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

2. Get currently playing song in Media Player?

I'd like to create an app that searches for lyrics for the current
playing song in media player. My supposition is that the media player
uses a service to play mp3's, to which I should connect with AIDL (can
I connect to another app's service?? If not, does the Media Player
share some ContentProvider?) and query it to get the current playing
song. I can't find this documented anywhere, probably because the
music player's source is currently closed?

Does any one know a way of doing this?

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

3. Paint.setTextSize & ascent & descent.

4. Installing ADT

5. Paint.setTextSize & ascent & descent

6. Incoming Call Event

7. call reject