Thread: Test to see whether a named process is running - platform independent

  1. #1
    Registered User
    Join Date
    Mar 2010
    Posts
    2

    Test to see whether a named process is running - platform independent

    Hi there,
    I'm trying to find a way of testing whether my process is already running when I try to spin it up. If it is already running, I then need to kill it. The problem is that the application is going to be deployed on both Windows XP and RHEL/CentOS 5 boxes.

    I have been able to track down OS-specific ways of testing to see if a named process is running, but is there any way to do it independent of operating system?

    We have been making heavy use of the ACE libraries, which allows us to perform a lot of operations which would usually be os-specific in a portable way, but I can't seem to fund a way of getting the process list.

    Any ideas?

    Thanks,
    Rik

  2. #2
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,130
    Do you really need the process list? I guess any system has a functionality to access named mutexes, so if you can aquire access, your instance is the first to run, if your access request times out, another instance is already running. At least on Windows, this is even faster than process scanning.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  3. #3
    Registered User
    Join Date
    Mar 2010
    Posts
    2

    Mutexes are process specific

    I did think about putting a giant mutex around the main function, but the problem is that a mutex guarantees mutual exclusion for threads within the same process. Two processes will have separate instances of the mutex.

    I have thought of three ways:
    1) Write the process id to file when the program spins up. Delete it when the programs stops and write a seg fault handler to delete it when the proram seg faults. If the file exists, another process is already running. This is good, but would require a fault handler, which I don't have a great deal of experience with.

    2) Have a batch file/bash script to kick off the application. Obviously the script would be OS specific. It would work, it would be quick to do, but it's not an elegant solution.

    3) Implement two versions of the class in one file with massive pre-processor guards, so that one complete implementation is for windows and the other for linux. Again, not so elegant, but it would work. The main issue is working out which OS we are running under at run time.

    Any thoughts?

  4. #4
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    Quote Originally Posted by RikSaunderson View Post
    I did think about putting a giant mutex around the main function, but the problem is that a mutex guarantees mutual exclusion for threads within the same process. Two processes will have separate instances of the mutex.

    I
    Are you sure you are talking about named mutexes?

    Mutex
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Capturing stderr from an execv()ed process
    By Angus in forum Linux Programming
    Replies: 1
    Last Post: 11-10-2009, 01:43 PM
  2. Problem running prime number test.
    By galactic_ronin in forum C++ Programming
    Replies: 25
    Last Post: 02-20-2008, 12:21 PM
  3. MinGW Linking GUI Program
    By Tonto in forum Tech Board
    Replies: 19
    Last Post: 08-23-2006, 03:28 PM
  4. C++ Operator Overloading help
    By Bartosz in forum C++ Programming
    Replies: 2
    Last Post: 08-17-2005, 12:55 PM
  5. MSVC Template Constructor/Assignment Errors
    By LuckY in forum Windows Programming
    Replies: 3
    Last Post: 07-22-2005, 02:57 PM

Tags for this Thread