Dear Tizen Community Members,
Updates for the Tizen Sensor Framework 3.0 release:-
* The Sensor Framework API exposed on sensor.git repository will be the same
and the changes are only on the underlying architecture and code.
* New Event Driven Sensor Framework Architecture:
+ Problems observed on the old architecture:
- Issues with event handling mechanism.
~Loss of events (as high as 76% event drop when event
registered for interval of 1ms) and duplicated events.
There is no information about clients and
their registered events in server.
There is no mechanism for server to send event
to client when event has occurred.
Clients send command to server (for receiving
events), based on their own interval tracking.
Client assumes event received is correct which
may not be the case.
~Use of VCONF for event handling IPC
VCONF not intended for IPC.
Very slow event handling mechanism.
- Thread safety issue
~ Global variables are used extensively in client code.
~ Difficult to reduce lock granularity in client code.
Big code locks with reduced granularity are used.
- Poor exception handling - example when a client application
crashes/terminates abruptly.
- Lot of unused and redundant code - Refactoring and Code
cleanup.
+ New Event Driven Sensor Framework Architecture:
- No loss of Events or duplicate events (verified that there is
no event drop when events are register for 1ms interval)
A separate event handling mechanism in both client and
server.
Events are available in plugin and delivered to server
based on the minimum interval across all clients.
The client Event Listener filters received events based
on registered event interval and triggers the event callback.
- Server tracks the information of the clients.
- Socket based IPC instead of VCONF for event handling –>
faster event handling.
- Sensor Framework Client specific changes:
Separate event handling mechanism - Separate e-poll
based listener and Event handler to filter and process events specific to each
client.
Client information are stored in a more structured form
- handles, sensors and registered events.
Thread safety Issue - Lock granularity can be reduced
because client information stored in a more structured form.
Command sockets used per sensor instead of per handle.
More commands added in the command channel to make it
more scalable architecture.
- Sensor Framework Server specific changes:
Event handling has been separated from command handling
code.
Single Event queue for sensor plugins.
Storage of all information in a structured way - about
clients, sensors and sensor usage.
More safety mechanisms in case of exceptions.
More granular implementation of the command handler
resulting in scalable architecture.
Extensive cleanup/restructuring of the unused and
redundant code.
- Plugin Layer:
Support for collecting events using event queue in all
plugins.
Separate client based sensor interval storage.
Removal of the redundant filter plugin layer.
* The performance of the current Sensor Fusion implementation does not meet the
standards available in competitor OS sensor framework.
+ we are currently looking to improve the Sensor Fusion algorithm
(decision to add it for 3.0 release after testing the results of
implementation).
* We have identified more areas for improvement in Sensor Framework code for
updation after 3.0. We will keep the community updated on future developments.
Feedback or comments are welcome. Please update your new requirements/ features
for sensor framework on JIRA.
Regards,
Ram
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
