Ok, so I get the gist of MediaFoundation:
When I start my App I create an IMFMediaSession.
When I want to play a file I create an IMFMediaSource, create the necessary IMFTopology, and I set it to the IMFMediaSession. Depending on the flag used (dwSetTopologyFlags) the new media source will either play immediately or just get added to a queue to be played by the MediaSession when the existing topologies/mediaSources are done playing.
Now my issue is cleaning up after old media sources.
Is there an event that is sent by the MediaSession right before the topology used is about to be removed? That way I could access the media source from there and call ShutDown on it (thus avoiding memory leaks) without having to keep references to previous mediaSessions myself in my code.
//=============================================================================== Update:
According to MSDN:http://msdn.microsoft.com/en-us/library/windows/desktop/aa372153%28v=vs.85%29.aspx
I need to call ShutDown on any IMFMediaSource I create, before releasing it.
With this in-mind, mixing MFSESSION_SETTOPOLOGY_FLAGS (immediate/clear_current with no flags) can cause a memory-leak, as the Session removes topologies from its queue without my application having the chance to call shutdown on their sources.
Also, if I call Shutdown on the current mediaSource before the next mediaSource's topology has been set (i.e. before I get the MESessionTopologyStatus event) then I can't playback the next mediaSource. Why? I don't know, msdn does not explain what resources are released when I call shudown on a mediaSource, so I guess something I still need in order to play the next mediaSource is being released...
My experience is that if you do not call Shutdown on Source, you will have memory leak. Check my project MFNode. There is a custom MediaSession (MFNodePlayer project).
If you uncomment the call to Shutdown on the source, you will see memory leak.
A lot of source expect you call Shutdown because you need to wait stop message from the source (they are usually asynchronous).
If you try to use the the source before it stops, you will face some strange error/behaviour and memory leak.
You have to wait the source to stop, in order to have a stable application. And calling Shutdown on source is here for that.
Related
A Realm holds a read lock on the version of the data accessed by it, so that changes made to the Realm on different threads do not modify or delete the data seen by this Realm. Calling this method releases the read lock, allowing the space used on disk to be reused by later write transactions rather than growing the file
Is there a matching function in Xamarin.Realm like in Objc/Swift's RLMRealm invalidate.
If not, is this a backlog item or is it not required(?) with the C# wrapper.
I think calling Realm.Refresh() would be a workaround - it will cause the Realm instance to relinquish the read lock it has at the moment and move it to the latest version which would free up the old version for compaction.
Ordinarily moving the read lock to the latest version would happen automatically if the thread you run on has a running CFRunLoop or ALooper, but on a dedicated worker thread you'd be responsible for calling Refresh() on your own to advance the read lock.
Please open an issue on https://github.com/realm/realm-dotnet for Invalidate() if Refresh() doesn't work for you.
I think you would use Realm.Close(). See:
https://realm.io/docs/xamarin/latest/api/class_realms_1_1_realm.html#a7f7a3199c392465d0767c6506c1af5b4
Closes the Realm if not already closed. Safe to call repeatedly. Note that this will close the file. Other references to the same database on the same thread will be invalidated.
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'm trying to deploy a patch to a service I created and replace the service file.
For that reason I need to stop the service so the file will be released.
I'm using sc \\remote stop svcname, then I query the service using sc \\remote query svcname until I see that it's state is STOPPED.
At this point the service file should be unlocked, and to be on the safe side I also delete the service using sc \\remote delete svcname.
Still, it doesn't seem to release the file and any deletion or change attempt fails.
I know one solution might be polling the file repeatedly, but I want to avoid this method.
Any suggestions?
Windows don't ensure the process providing the service terminates when the service is stopped (the process may provide more than one service). It just considers the service stopped when it handles the message sent to it.
So if the service process has a bug and does not properly release resources, they may still be locked. I would probably wait a little and than simply terminate the process.
There is also a tool from Microsoft called handle.exe (this is command-line version, they also have a GUI-one) that can list which processes hold the file open. It should be possible to get the same information programmatically, but I am not sure of the exact calls to make (and you need administrator privileges; you have to give them to the tool too). That way you can check whether the file is open, by which process and wait for it to terminate or force-terminate it if you didn't know which one it is.
I need to track to a log when a service or application in Windows is started, stopped, and whether it exits successfully or with an error code.
I understand that many services do not log their own start and stop times, or if they exit correctly, so it seems the way to go would have to be inserting a hook into the API that will catch when services/applications request a process space and relinquish it.
My question is what function do I need to hook in order to accomplish this, and is it even possible? I need it to work on Windows XP and 7, both 64-bit.
I think your best bet is to use a device driver. See PsSetCreateProcessNotifyRoutine.
Windows Vista has NotifyServiceStatusChange(), but only for single services. On earlier versions, it's not possible other than polling for changes or watching the event log.
If you're looking for a user-space solution, EnumProcesses() will return a current list. But it won't signal you with changes, you'd have to continually poll it and act on the differences.
If you're watching for a specific application or set of applications, consider assigning them to Job Objects, which are all about allowing you to place limits on processes and manage them externally. I think you could even associate Explorer with a job object, then all tasks launched by the user would be associated with your job object automatically. Something to look into, perhaps.
I would like to create an application that will monitor apps running on my machine, and respond to situations where an application has beachballed. Is it possible (using any of the various OSX programming tools -- I'll teach myself Objective-C for this) to detect whether this has happened? If so, can someone give me a short code sample that does so?
I'm afraid I don't the actual classes or functions involved, but I can give you an outline of the process.
First, understand that every Application (perhaps every Window) has an event queue backing it. Each is serviced by a thread that just pops an event* off the queue, does some processing, and then returns to waiting for the next event. A "beachball" comes up (when forced by the system) when the event queue isn't getting serviced quickly enough. A "frozen" event queue implies that an application locked up when responding to some event in the past.
Now - outside of debugging contexts - you shouldn't be able to reach into another application and fiddle with a thread's event queue to see if its getting serviced. But what you could do instead is periodically post an event that would illicit a response, and if ever that response doesn't come you know the application is "locked up".
This constitutes polling, so be wary of the performance implications.
*Events are things like key down, key up, mouse moved, repaint, and so on.
Besides the WindowServer itself, the other system components that I know of that can detect unresponsiveness are the force quit dialog, spindump (which collects sampling profiles of applications while they are unresponsive), and Activity Monitor (presumably via its pmTool privileged subprocess). Perhaps running strings on pmTool might provide hints about what system calls to use?
Note that none of these evidently does its job by polling, because no application is ever detected as unresponsive until it fails to respond to an event — if an application hangs/does a lot of computation without checking its event queue, but it receives no events during that time, then it is not reported as unresponsive.