[process] Determine if a process is still running?
Hi all, I'm interested in a cross platform way to determine if a process as identified by process ID is still running. There is no parent/child relationship between the running and detecting processes. However it is easy in my particular scenario for the running process to communicate its ID to the detecting process for later evaluation. I know that I can write separate Windows and Posix implementations that would work. But I'd prefer a cross-platform implementation rather than conditionally calling native API's. I can see that boost::process supports obtaining a process ID. The question is can boost::process use this ID to determine if a given process, which was not launched as a child, is still running? Thanks in advance for any suggestions. Best, -- Allen Cronce
On Mon, 06 Sep 2010 21:09:33 +0200, Allen Cronce <allenslists@gmail.com> wrote:
[...]I can see that boost::process supports obtaining a process ID. The question is can boost::process use this ID to determine if a given process, which was not launched as a child, is still running?
I assume you refer to Boost.Process 0.4 which has been released recently and is currently heavily discussed on the Boost developer's list. There is a proposal at <http://www.highscore.de/boost/gsoc2010/process/appendices.html> how to create a snapshot of currently running processes. The function create_snapshot() wasn't finished in time though to ship it with 0.4. There were some more ideas to filter processes returned by create_snapshot() (eg. if you are only interested in processes owned by a certain user). But I think in general this kind of function could help you? You could then either iterate through the processes in the snapshot or filter with the process ID directly? Boris
Hi Boris, Thanks for getting back to me. We're currently using boost::process 0.31. I wasn't aware of 0.4, or any recent activity in boost::process. I'll keep that in mind the next time I have boost::process questions. As far as the create_snapshot proposal is concerned, that looks interesting. Unfortunately I need a solution very soon, so my guess is that I'll have to roll my own this time. Best, -- Allen Cronce On Sep 6, 2010, at 1:54 PM, Boris Schaeling wrote:
On Mon, 06 Sep 2010 21:09:33 +0200, Allen Cronce <allenslists@gmail.com> wrote:
[...]I can see that boost::process supports obtaining a process ID. The question is can boost::process use this ID to determine if a given process, which was not launched as a child, is still running?
I assume you refer to Boost.Process 0.4 which has been released recently and is currently heavily discussed on the Boost developer's list.
There is a proposal at <http://www.highscore.de/boost/gsoc2010/process/appendices.html> how to create a snapshot of currently running processes. The function create_snapshot() wasn't finished in time though to ship it with 0.4. There were some more ideas to filter processes returned by create_snapshot() (eg. if you are only interested in processes owned by a certain user). But I think in general this kind of function could help you? You could then either iterate through the processes in the snapshot or filter with the process ID directly?
Boris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hey, it's actually extremely simple. Feel free to use the following code if it helps you: bool Process::isRunning(pid_t pID) { if (pID <= 0) { return false; } #if defined(PLATFORM_ENVIRONMENT_WIN32) HANDLE handle = OpenProcess(SYNCHRONIZE, false, pID); if (!handle) { return false; } else { CloseHandle(handle); return true; } #elif defined(PLATFORM_ENVIRONMENT_UNIX) if (kill(pID, 0) == -1) { return false; } else { return true; } #endif } Just keep in mind that zombie pids will be reported as running. On 7 September 2010 23:59, Allen Cronce <allenslists@gmail.com> wrote:
Hi Boris,
Thanks for getting back to me. We're currently using boost::process 0.31. I wasn't aware of 0.4, or any recent activity in boost::process. I'll keep that in mind the next time I have boost::process questions.
As far as the create_snapshot proposal is concerned, that looks interesting.
Unfortunately I need a solution very soon, so my guess is that I'll have to roll my own this time.
Best, -- Allen Cronce
On Sep 6, 2010, at 1:54 PM, Boris Schaeling wrote:
On Mon, 06 Sep 2010 21:09:33 +0200, Allen Cronce <allenslists@gmail.com> wrote:
[...]I can see that boost::process supports obtaining a process ID. The question is can boost::process use this ID to determine if a given process, which was not launched as a child, is still running?
I assume you refer to Boost.Process 0.4 which has been released recently and is currently heavily discussed on the Boost developer's list.
There is a proposal at < http://www.highscore.de/boost/gsoc2010/process/appendices.html> how to create a snapshot of currently running processes. The function create_snapshot() wasn't finished in time though to ship it with 0.4. There were some more ideas to filter processes returned by create_snapshot() (eg. if you are only interested in processes owned by a certain user). But I think in general this kind of function could help you? You could then either iterate through the processes in the snapshot or filter with the process ID directly?
Boris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Sun, Aug 1, 2010 at 7:25 AM, TONGARI <tongari95 <at> gmail.com> wrote:
Hi, I just modified a test program taken from AGG's examples to test the polygon clipping capability of following libraries. *Boost.Polygon *GPC *Clipper
Here are some observations: 1) The proccesing speed (fastest to slowest): Clipper > GPC > Boost.Polygon 2) With "xor", although the results seems the same, they have different countours numbers (Clipper the least). 3) Boost.Polygon has a strange behavior that it sometimes produces erroneous vertical lines within the polygons. In this example, with "or" operation you'll see that.
I put the test files here: http://tinyurl.com/2axoqxc
Anyone who wants to compile it will also need AGG and Clipper on your computer.
Thanks for taking a look at my library and performing this comparison. I've never seen a comparison with clipper before, I've never heard of clipper and would like to learn more. Can you provide a link or reference? I found a sourceforge site with minimal description of clipper, but it left me with a lot of unanswered questions. I was able to access your code through the tinyurl, but I haven't followed up on it yet. Was it possible that the "erroneous" vertical lines within the polygons were the hole fracturing lines that I insert if your result type is polygon_concept rather than polygon_with_holes_concept? As far as the number of contours produced. Boost.Polygon always provides the maximum number of outer contours and the minimum number of inner contours. Polygons touching at only one point are reported as separate contours. Holes touching at only one point are reported as a single contour. I would argue this is the most correct policy to have. I generally see mismatch between contour count and vertex count for different polygon clippers on the same data even before issues related to numerical error are introduced that can muddy the water still further. Such differences do not necessarily indicate there is a problem. As for performance, I expect GPC to be faster than Boost.Polygon for small test cases. It is a little tricky to conduct performance comparisions between different polygon clipping libraries because performance can depend quite a bit on input. My primary goal in the design and implementation of the Boost.Polygon any angle polygon clipping (and related) capability was optimal or near-optimal algorithmic time and space complexity to allow the algorithm to scale to extremely large inputs gracefully. If a simpler and clearly sub-optimal algorithm (like GPC) is faster for small inputs it doesn't necessarily mean there is anything wrong with the implementation of Boost.Polygon. I have improved runtime for the any angle capability significantly since I originally got it correct. Based on the performance study I did (see documentation) there is a ~10X upper bound on improvement in the constant factor for the any angle implementation if you use the efficiency of the similar manhattan capability as a lower bound. Any improvement beyond that implies a completely new algorithm. By the way, I would have responded sooner, but I haven't been monitoring the boost-users list. Thanks again, Luke
2010/9/8 Simonson, Lucanus J <lucanus.j.simonson@intel.com>
Was it possible that the "erroneous" vertical lines within the polygons were the hole fracturing lines that I insert if your result type is polygon_concept rather than polygon_with_holes_concept?
The result type is std::list<polygon_type>, polygon_set_concept I think, where polygon_type I defined is polygon_concept.
This small program shows the visual result of 2 polygons clipping, and the resultant ploygons are represented as blue outlines(contours). The input ploygons are taken from Boost.Polygon's unit test, so I would expect the result to be correct at least in this case. But when doing "union", Boost.Polygon shows me the wierd result,* [1]*, seems like all distinct polygons are merged into one contour, while the correct one should be *[2] Screen shots: [1]**http://tinyurl.com/27fwxfn* *[2]http://tinyurl.com/26w3qj6* I'm not sure what's wrong here. Thanks
2010/9/17 TONGARI <tongari95@gmail.com>
I'm not sure what's wrong here. Well, the reaI problem is that I just mistakenly expect Boost.Polygon to output the holes as distinct polygons, isn't it?
Yes. Boost.Polygon has two output modes for polygons. One where the holes are fractured or "key-holed" out to the outer boundary and one where holes are reported as polygons in a list associated with their outer boundaries through the polygon_with_holes_concept. Many polygon clippers report holes as polygons with opposite winding and not associated with their outer shells. Keyholing and associating holes to outer boundary are features of the algorithm, but if you expected the naïve behavior it could be confusing. It is easy to take the polygon with holes output of Boost.Polygon and build a list of polygons and holes with opposite winding to emulate the output of a simpler polygon clipper (to satisfy the interface of a legacy application, for instance). Regards, Luke
participants (5)
-
Allen Cronce -
Boris Schaeling -
Rok Breulj -
Simonson, Lucanus J -
TONGARI