I have searched the Internet but failed to find a satisfactory answer. What is the threading model present in an OSGi container? Does it simply spawn a new thread to each registered bundle e.g.? Any reference regarding the threading model would be great.
You have not found anything because there is no such thing as an "OSGi threading model". Bundles simply exist and don't "have threads" unless they start them.
The OSGi framework follows a synchronous model, ie. everything happens in a strict order. Bundles are not executed in threads (but they have their own classloader instances). There are some exceptions, though. For example, when an event is raised via the postEvent method, the delivery of the event is done asynchronously, usually implemented in many framework implementations as a thread.
When you start a bundle, code in activator is executed in one thread, similar to the 'main' thread. When the main thread completes its execution, bundle is changed from the 'Starting' state to 'Active' state. So it is better to execute time consuming code in another thread and starting another thread from the main thread.
When service method gets called from service consumer. At that time, the code written in the service method get executed in service consumer's thread.
I didn't find any difference between static variables and local variable in the service method.
Besides some special cases (Events/Listeners) the application threads are neighter managed nor restricted. You can use threading freely. You do need to be aware that some operations in the bundle lifecylce must be (therefore) thread safe and you need to be very carefull to tear down threads cleanly. You also need to be carefull not to block OSGi operations needlessly long.
Related
The Windows Antimalware scan Interface (AMSI) contains abstractions which can be used to call the currently active virus scanner in Windows:
https://learn.microsoft.com/en-us/windows/desktop/amsi/antimalware-scan-interface-functions
There are 2 methods related to initialization:
AmsiInitialize
AmsiUninitialize
AmsiInitialize returns "A handle of type HAMSICONTEXT that must be passed to all subsequent calls to the AMSI API.".
After initialization is complete, I can use AmsiScanBuffer to scan a buffer for malware.
My question:
Can I use the same context concurrently from many threads in my application, or do I need to create one per thread from which I'm going to call the methods?
Reading the documentation, for AsmiUnitialize, it tells me that When the app is finished with the AMSI API it must call AmsiUninitialize.. This tells me that the context can be used for many calls, but it doesn't tell me anything about thread safety or concurrency.
Generally, API calls that are not specifically marked as thread-safe are not (this is usually true for any library). The easiest solution is to open an AMSI handle per thread.
(P.S. This only works with Windows Defender so far as I 've tested).
I have an app which needs almost no user interaction, but requires Geofences. Can I run this entirely within a background service?
There will be an Activity when the service is first run. This Activity will start a service and register a BroadcastReceiver for BOOT_COMPLETED, so the service will start at boot. It's unlikely that this Activity will ever be run again.
The service will set an Alarm to go off periodically, which will cause an IntentService to download a list of locations from the network. This IntentService will then set up Geofences around those locations, and create PendingIntents which will fire when the locations are approached. In turn, those PendingIntents will cause another IntentService to take some action.
All this needs to happen in the background, with no user interaction apart from starting the Activity for the first time after installation. Hence, the Activity will not interact with LocationClient or any location services.
I've actually got this set up with proximityAlerts, but wish to move to the new Geofencing API for battery life reasons. However, I have heard that there can be a few problems with using LocationClient from within a service. Specifically, what I've heard (sorry, no references, just hearsay claims):
location client relies on ui availability for error handling
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread
When I've investigated, I can't see any reason why this would be the case, or why it would stop my doing what I want. I was hoping it would be almost a drop-in replacement for proximityAlerts...
Can anyone shed some light on things here?
The best thing would be to just try it out, right? Your strategy seems sound.
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread.
I know this to be not true. I have a Service that is started from an Activity, and the connection callback is called.
I dont know about proximity alerts; but I cant seem to find an API to list my GeoFences. I am worried that my database (sqlite) and the actual fences might get out of sync. That is a design flaw in my opinion.
The reason LocationClient needs UI, is that the device may not have Google Play Services installed. Google has deviced a cunning and complex mechanism that allows your app to prompt the user to download it. The whole thing is horrible and awful in my opinion. Its all "what-if what-if" programming.
(They rushed a lot of stuff out the door for google IO 2013. Not all of it are well documented, and some of it seems a bit "rough around the edges").
I have created apps in the past that would have web pages that would call the persistence layer to get some query results or to insert, delete, etc against a db. However, nothing was left running in the background except for the persistence layer. Now I need to develop an app that has an process that is always running in the background, which is waiting for messages to come thru a zeromq messaging system (cannot change this at this point). I am a little lost as to how to setup the object so that it can always be running and yet I can control or query the results from the object.
Is there any tutorial/examples that covers this configuration?
Thanks,
You could use some kind of timer, to start a method every second to look at a specific ressource and process the input taken from that.
If you use Spring than you could have a look at the #Scheduled annotation.
If your input is some kind of java method invokation, than have a look at the java.util.concurrent Package, and concurrent programming at all. -- But be aware of the fact, that there are some restictions one creating own Threads in an EJB environment.
Before the application terminates its
execution, COM must be shut down
again. (Failure to shut down COM could
result in execution errors when
another program attempts to use COM
services .)
The above quote implies that, right?
No it doesn't.
If you fail to properly release all references to an out of process COM server and correctly close down COM it could lead to that instance of that service being in an odd state (everything should be OK after releasing all references, but sometimes COM might cache part of the out of process marshalling layer).
An out of process COM service can be designed to have separate component instances for each client (within or across services) that are completely independent (even if hosted in the same process), in which case it is hard to see how a failure of one client would affect other instances (other than wasting memory on instances until COM finally times them out). If the instances share state they can of course interfere even if the clients operate perfectly to the rules.
It is rather important that you quote the source of that quote so we can get the context. As near as I can see, you got that from a book about DirectShow programming. What it actually refers to is the need to call CoUninitialize().
Yes, that's kinda important. A thread should call CoInitializeEx() to initialize the COM infrastructure before it starts using any of the COM API functions. You really should call CoUninitialize() when that threads ends so stuff is properly cleaned up. Typically at the end of your program's main() function. Failure to do so may make another app fail when it finds a register class factory that in fact is dead.
This otherwise has nothing to do with a COM out-of-process server having to restrict itself in any way. You specify sharing mode with the REGCLS argument to CoRegisterClassObject(). Of course, a server should not exit and call CoUninitialize until all its objects are released.
I am planning to use the State Machine WorkFlow of Windows Workflows.
The state machine will be receiving events from two separate threads, the state machine of course will both change its state and execute actions based on its current state and the event that came in.
My question is, is the state machine of windows workflow thread safe, meaning that it will guarantee the correct state change when two threads access it at the same time?
Workflow execution follows single-threaded apartment conventions - that is, one particular instance of a workflow can only be executed by one thread at a time within any runtime. This is by design.
The workflow runtime uses an internal scheduling queue to execute operations for workflow instances, so two threads invoking operations on the same workflow instance will be serialized to the scheduler queue first, then invoked in sequence either by a new thread scheduled by the runtime (default scheduling) or by the thread donated by the calling context for each operation (manual scheduling).
When using the persistence service, the workflow runtime also ensures that the database version is synchronized as well - another workflow runtime running on another process / machine cannot load the same workflow instance from persistence if it is currently open by another workflow runtime.
This means that you don't have to be concerned with thread-safety on code executing within a workflow model (eg you don't have to lock property setters), and you don't have to be concerned with race conditions.
What's your interpretation of this kind of thing in the Microsoft Documentation for (for example) the State Activity CLass in System.Workflow.Activitie:
Thread Safety
Any public static (Shared in Visual
Basic) members of this type are thread
safe. Any instance members are not
guaranteed to be thread safe.
Similar passages are given on many relevent classes. My inference is "no" not thread safe for the usage you're intending.