You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Andrew Black <ab...@roguewave.com> on 2006/08/24 22:46:10 UTC
Use of Windows Jobs API in exec utility
Greetings all.
I have started looking at what would be required to implement the child
process limits logic and child process statistic gathering functionality
in the exec utility on Windows.
The research I have done indicates that it is possible to accomplish
both tasks using the job object API (
http://msdn.microsoft.com/library/en-us/dllproc/base/job_objects.asp ).
The problem with using this API is that it was introduced with Windows
2000 (I think) and is protected by a 'Legacy Macro' (
http://msdn.microsoft.com/library/en-us/winprog/winprog/using_the_windows_headers.asp
). In this case, the guarding macro is _WIN32_WINNT, which needs to be
defined to 0x0500 or higher prior to the inclusion of windows.h.
There are a few tactics we could take with regards to this situation,
and I would appreciate thoughts on which should be taken.
The simplest method would be to require the exec utility to be built on
Windows 2000 or newer versions of the operating system. The trade off
of doing so is that it would be more difficult to build the utility, and
by extension the library, on older operating systems. Unfortunately, I
don't know what older versions of windows that the library is still able
to build on.
A more complex method would be to define this macro unconditionally, but
guard the uses of the job object API by runtime checks, similar to the
checks around the GenerateConsoleCtrlEvent calls. This could allow the
utility to build with newer compilers on older operating systems, but it
would still fail to build with versions of the windows SDK prior to the
release of Windows 2000.
The most compatible way to do things would be to guard the uses of the
job object API by #ifdef directives. However, it would make the code
harder to read, and it might take some work to figure out what macro(s)
to check.
--Andrew Black
Re: Use of Windows Jobs API in exec utility
Posted by Andrew Black <ab...@roguewave.com>.
Martin Sebor wrote:
> Andrew Black wrote:
>> Greetings all.
>>
>> I have started looking at what would be required to implement the child
>> process limits logic and child process statistic gathering functionality
>> in the exec utility on Windows.
>>
>> The research I have done indicates that it is possible to accomplish
>> both tasks using the job object API (
>> http://msdn.microsoft.com/library/en-us/dllproc/base/job_objects.asp ).
>
> I assume you're looking at this API because it lets you gather
> process statistics for not just the child process but also for
> the grandchildren, correct? If so, I'm not sure such a total
> would be more interesting than the times for just the child
> alone (i.e., the Windows analogue of struct rusage obtained
> by the getrusage() call, which I think is GetProcessTimes()).
>
The main reason I was looking at the job API was so that an analog to
the ulimit switch could be added on the windows side. I don't know how
important this is, but my thinking was that it should be considered if
we wished to try to maintain some kind of feature parity between windows
and the rest of the operating systems.
--Andrew Black
Re: Use of Windows Jobs API in exec utility
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Greetings all.
>
> I have started looking at what would be required to implement the child
> process limits logic and child process statistic gathering functionality
> in the exec utility on Windows.
>
> The research I have done indicates that it is possible to accomplish
> both tasks using the job object API (
> http://msdn.microsoft.com/library/en-us/dllproc/base/job_objects.asp ).
I assume you're looking at this API because it lets you gather
process statistics for not just the child process but also for
the grandchildren, correct? If so, I'm not sure such a total
would be more interesting than the times for just the child
alone (i.e., the Windows analogue of struct rusage obtained
by the getrusage() call, which I think is GetProcessTimes()).
> The problem with using this API is that it was introduced with Windows
> 2000 (I think) and is protected by a 'Legacy Macro' (
> http://msdn.microsoft.com/library/en-us/winprog/winprog/using_the_windows_headers.asp
> ). In this case, the guarding macro is _WIN32_WINNT, which needs to be
> defined to 0x0500 or higher prior to the inclusion of windows.h.
>
> There are a few tactics we could take with regards to this situation,
> and I would appreciate thoughts on which should be taken.
>
> The simplest method would be to require the exec utility to be built on
> Windows 2000 or newer versions of the operating system. The trade off
> of doing so is that it would be more difficult to build the utility, and
> by extension the library, on older operating systems. Unfortunately, I
> don't know what older versions of windows that the library is still able
> to build on.
In general, we should try to accommodate all versions of Windows
at least all the way through Windows NT (it's probably safe not
to worry about Windows 98 or prior).
Martin