- Description has changed:
Diff:
~~~~
--- old
+++ new
@@ -1,3 +1,7 @@
-Setting up IMM Object Implementer (OI) is not handled in a correct and
consistent way. There is also a lot of redundant code. In some places (but not
everywhere) a thread is used to prevent the main thread from ‘hanging’ a long
time but this is done in an incorrect way. See also ticket [#1527]
+Setting up IMM Object Implementer (OI) is not handled in a correct and
consistent way. There is also a lot of redundant code. In some places (but not
everywhere) a thread is used to prevent the main thread from ‘hanging’ a long
time but this is done in an incorrect way. See also ticket [#1527]
-This ticket is going to introduce an dedicated thread for IMM OiHandler. Any
other thread wants to perform on the IMM OiHandler, must send requests to this
dedicated thread. Refer to the ticket [#1609].
+Handle all OI functionality in a separate thread including a poll loop for
callback handling, recovery of IMM handles etc. Today all of this is done in
the main thread except recovery of IMM handles.
+Use a mailbox to communicate with other threads (main thread). Encapsulate
communication in C++ interface. Do not handle client/stream database in the OI
thread. This includes the runtime objects for streams. If for example a runtime
attribute value is requested the OI shall ask for the value via the interface.
Also other changes and settings shall be handled this way.
+Do not handle any check-pointing (msb) in the OI thread
+
+It is recommended that ticket [#2149] log: Create a C++ wrapper for handling
IMM api is implemented first
~~~~
---
** [tickets:#1531] LOG: Introduce an dedicated IMM OiHandler handler thread**
**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Thu Oct 08, 2015 11:14 AM UTC by elunlen
**Last Updated:** Thu Jul 14, 2016 03:44 AM UTC
**Owner:** Vu Minh Nguyen
Setting up IMM Object Implementer (OI) is not handled in a correct and
consistent way. There is also a lot of redundant code. In some places (but not
everywhere) a thread is used to prevent the main thread from ‘hanging’ a long
time but this is done in an incorrect way. See also ticket [#1527]
Handle all OI functionality in a separate thread including a poll loop for
callback handling, recovery of IMM handles etc. Today all of this is done in
the main thread except recovery of IMM handles.
Use a mailbox to communicate with other threads (main thread). Encapsulate
communication in C++ interface. Do not handle client/stream database in the OI
thread. This includes the runtime objects for streams. If for example a runtime
attribute value is requested the OI shall ask for the value via the interface.
Also other changes and settings shall be handled this way.
Do not handle any check-pointing (msb) in the OI thread
It is recommended that ticket [#2149] log: Create a C++ wrapper for handling
IMM api is implemented first
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
