Getting an application "handle"?

Hi,

I have a project where there's a service running and it's serving information to a number of applications. What I want to do is when an app connects to the service it passes a handle to itself so the service can watch or wait on that handle and take appropriate action if the application terminates.

I need something that will work with basic Win32 apps.

Also, if it's not possible in this context, could I create an event in a signaled state, pass it to the service on connection and if the app disappears/crashes/etc. then take appropriate action? I assume that if an app exits or crashes then the event would be released and I can detect that.

Thanks!

Any of that is possible. How are the apps communicating with your service?

Well you can send to your application the other application's ProcessID ( its a simpled DWORD) from which point u can obtain a HANDLE using OpenProcess, if you specify the SYNCHRONIZE flag you can use WaitForSingleObject on the obtained handle to determine when the other process quits. I hope that I understood what you want to do correctly.

Kolkoo, I think I understand, I was actually just discovering functions related to that kind of thing when I read the replies to the post, thanks!

Arjay, I am using an ATL COM service which acts as a kind of authentication server for some special software. The basic idea is the application connects and requests some special info related to the app itself and "checks it out" exclusively until it is done with it.

The problems I wish to avoid are the application crashing and the data never being checked back in, or the app exiting ungracefully and doing the same thing as a crash. I figured the best way to remedy this would be for the service itself to monitor the connected apps and if the app disappears, revert back to the checked in state so another app can gain control of the information.

I was thinking about those COM.. what are they, those event thingies (I'm really new to COM, sorry for my lack of proper terminology) but I'm thinking it's simpler in the end if I just have a thread watching the connected processes and then act accordingly if one drops. I need to do something in short order as well just to make sure everything keeps up to date.

One thing you can do is to create a ping interface and have your clients ping the COM server periodically. On the server, keep a list of the clients and when you haven't receive a ping from a client for some period, remove the client from your list.

I was thinking of that, but how do I keep track of who owns what in the sense of the data they check out? If two apps of the same type are started and both check something out, then app 1 dies, how do I know which of the two items app 1 checked out?

Does the COM interface allow me to tell which app is accessing what data?

What you can do is have an interface with three methods: Register, Ping, and Unregister.

When your app starts up it calls the register method which returns a token (integer or guid). As your app runs it calls ping periodically and passes the token. When the app shuts down it calls Unregister (again passing the token). For any checkout/checkin methods, in addition to the other params, you pass in the token.

Inside the service, you keep track of a list of tokens and a timestamp for each token. When you receive a Ping call, you update the timestamp for that particular token. Every so often you walk the list and remove the items where the token hasn't been updated in some XXX time period (and perform any checkin cleanup associated with that token).

NOTE: The operations on this list must be thread safe, because the interface calls can come in on multiple threads

Yep, everything is thread safe.

Ok, I get what you're saying about the registering and pinging. I like that idea, keeps things simple and I already have a mechanism for keeping things separate in terms of a token.

Thanks for the help, much appreciated!