public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
* Why is _WIN64 not defined as 1 in _cygwin.h?
       [not found] <1016746971.2414349.1637763426878.ref@mail.yahoo.com>
@ 2021-11-24 14:17 ` Z. Majeed
  2021-11-25 13:07   ` Corinna Vinschen
  0 siblings, 1 reply; 11+ messages in thread
From: Z. Majeed @ 2021-11-24 14:17 UTC (permalink / raw)
  To: cygwin-developers

I've run into this problem while porting Intel oneTBB to cygwin - there are some places where I need to use Win32 versions of code in oneTBB for cygwin because the Linux version is not supported in cygwin - one example is the missing VmPeak stat in /proc/self/status
This means the cygwin port sometimes needs to conditionally include windows.h
This leads to the Windows 64-bit feature test macro _WIN64 getting defined with no value in /usr/include/w32api/_cygwin.h - full discussion here https://cygwin.com/pipermail/cygwin-developers/2012-July/010732.html
/* _WIN64 is defined by the compiler specs when targeting Windows.   The Cygwin-targeting gcc does not define it by default, same as   with _WIN32.  Therefore we set it here.  The result is that _WIN64   is only defined if Windows headers are included. */#ifdef __x86_64__#define _WIN64#endif
This gives compile errors wherever _WIN64 is used in oneTBB code in expressions like
#if _WIN32 || _WIN64
e.g. at https://github.com/oneapi-src/oneTBB/blob/master/test/tbbmalloc/test_malloc_compliance.cpp#L38
The _WIN64 predefined macro is documented at https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
"_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined."
Why has cygwin chosen to define _WIN64 with no value?
Can _WIN64 instead be defined as 1 per Microsoft specification?
My port of oneTBB to cygwin is described at https://github.com/oneapi-src/oneTBB/issues/156
Thanks,Zartaj


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-24 14:17 ` Why is _WIN64 not defined as 1 in _cygwin.h? Z. Majeed
@ 2021-11-25 13:07   ` Corinna Vinschen
  2021-11-25 18:06     ` Z. Majeed
  0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2021-11-25 13:07 UTC (permalink / raw)
  To: cygwin-developers

On Nov 24 14:17, Z. Majeed wrote:
> /* _WIN64 is defined by the compiler specs when targeting Windows. 
>  The Cygwin-targeting gcc does not define it by default, same as 
>  with _WIN32.  Therefore we set it here.  The result is that _WIN64 
>  is only defined if Windows headers are included. */#ifdef
> __x86_64__#define _WIN64#endif This gives compile errors wherever
> _WIN64 is used in oneTBB code in expressions like #if _WIN32 || _WIN64
> e.g. at
> https://github.com/oneapi-src/oneTBB/blob/master/test/tbbmalloc/test_malloc_compliance.cpp#L38
> The _WIN64 predefined macro is documented at
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
> "_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64.
> Otherwise, undefined." Why has cygwin chosen to define _WIN64 with no
> value?

Because it was sufficient at the time and nobody actually cared until
today, I guess.

As for mixing Cygwin and Windows calls, I'd like to point out
https://cygwin.com/faq.html#faq.programming.64bitporting

Not saying you did something wrong, but the fact that the long datatype
differs in size requires some careful checking when porting stuff.


> Can _WIN64 instead be defined as 1 per Microsoft specification?

Note that this is just the Cygwin-specific part of the mingw-w64
project, not Cygwin itself.  If you want to change that, just send a
patch to the mingw-w64 mailing list.


Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-25 13:07   ` Corinna Vinschen
@ 2021-11-25 18:06     ` Z. Majeed
  2021-11-25 18:51       ` Corinna Vinschen
  0 siblings, 1 reply; 11+ messages in thread
From: Z. Majeed @ 2021-11-25 18:06 UTC (permalink / raw)
  To: cygwin-developers

Thanks for clearing that up - I'll send a patch to mingw-w64-public

The porting tip is appreciated - luckily the need for Win32 in the port has been minimal - it may be obviated completely if I can add VmPeak support - and take care of the other issue - a VmSize number that does not match Win32 PagefileUsage

 On Thursday, November 25, 2021, 08:08:24 AM EST, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

On Nov 24 14:17, Z. Majeed wrote:
> /* _WIN64 is defined by the compiler specs when targeting Windows. 
>  The Cygwin-targeting gcc does not define it by default, same as 
>  with _WIN32.  Therefore we set it here.  The result is that _WIN64 
>  is only defined if Windows headers are included. */#ifdef
> __x86_64__#define _WIN64#endif This gives compile errors wherever
> _WIN64 is used in oneTBB code in expressions like #if _WIN32 || _WIN64
> e.g. at
> https://github.com/oneapi-src/oneTBB/blob/master/test/tbbmalloc/test_malloc_compliance.cpp#L38
> The _WIN64 predefined macro is documented at
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
> "_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64.
> Otherwise, undefined." Why has cygwin chosen to define _WIN64 with no
> value?

Because it was sufficient at the time and nobody actually cared until
today, I guess.

As for mixing Cygwin and Windows calls, I'd like to point out
https://cygwin.com/faq.html#faq.programming.64bitporting

Not saying you did something wrong, but the fact that the long datatype
differs in size requires some careful checking when porting stuff.



> Can _WIN64 instead be defined as 1 per Microsoft specification?


Note that this is just the Cygwin-specific part of the mingw-w64
project, not Cygwin itself.  If you want to change that, just send a
patch to the mingw-w64 mailing list.


Corinna


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-25 18:06     ` Z. Majeed
@ 2021-11-25 18:51       ` Corinna Vinschen
  2021-11-26 10:47         ` Corinna Vinschen
  0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2021-11-25 18:51 UTC (permalink / raw)
  To: cygwin-developers

On Nov 25 18:06, Z. Majeed wrote:
> Thanks for clearing that up - I'll send a patch to mingw-w64-public
> 
> The porting tip is appreciated - luckily the need for Win32 in the
> port has been minimal - it may be obviated completely if I can add
> VmPeak support - and take care of the other issue - a VmSize number
> that does not match Win32 PagefileUsage

Yeah, improving Cygwin's /proc/self/status output would be a nice
option as well, if you'd like to take a stab at it...?


Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-25 18:51       ` Corinna Vinschen
@ 2021-11-26 10:47         ` Corinna Vinschen
  2021-11-26 14:33           ` Z. Majeed
  0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2021-11-26 10:47 UTC (permalink / raw)
  To: cygwin-developers

On Nov 25 19:51, Corinna Vinschen wrote:
> On Nov 25 18:06, Z. Majeed wrote:
> > Thanks for clearing that up - I'll send a patch to mingw-w64-public
> > 
> > The porting tip is appreciated - luckily the need for Win32 in the
> > port has been minimal - it may be obviated completely if I can add
> > VmPeak support - and take care of the other issue - a VmSize number
> > that does not match Win32 PagefileUsage
> 
> Yeah, improving Cygwin's /proc/self/status output would be a nice
> option as well, if you'd like to take a stab at it...?

Btw., wouldn't it be great to use your Windows limitMem function as
template to implement getrlimit/setrlimit(RLIMIT_AS) inside Cygwin?


Thanks,
Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-26 10:47         ` Corinna Vinschen
@ 2021-11-26 14:33           ` Z. Majeed
  2021-11-26 16:07             ` Corinna Vinschen
  0 siblings, 1 reply; 11+ messages in thread
From: Z. Majeed @ 2021-11-26 14:33 UTC (permalink / raw)
  To: cygwin-developers, Corinna Vinschen

Good idea! I planned to combine Linux and Windows parts of the failing test to reproduce the inconsistent VmSize issue - but making use of TBB code for a cygwin feature is great - I actually needed RLIMIT_AS for this port too
I looked at fhandler_process.cc last night - adding VmPeak seems just couple lines using Win32 PeakPagefileUsage
 
  On Fri, Nov 26, 2021 at 5:47 AM, Corinna Vinschen<corinna-cygwin@cygwin.com> wrote:   On Nov 25 19:51, Corinna Vinschen wrote:
> On Nov 25 18:06, Z. Majeed wrote:
> > Thanks for clearing that up - I'll send a patch to mingw-w64-public
> > 
> > The porting tip is appreciated - luckily the need for Win32 in the
> > port has been minimal - it may be obviated completely if I can add
> > VmPeak support - and take care of the other issue - a VmSize number
> > that does not match Win32 PagefileUsage
> 
> Yeah, improving Cygwin's /proc/self/status output would be a nice
> option as well, if you'd like to take a stab at it...?

Btw., wouldn't it be great to use your Windows limitMem function as
template to implement getrlimit/setrlimit(RLIMIT_AS) inside Cygwin?


Thanks,
Corinna
  

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-26 14:33           ` Z. Majeed
@ 2021-11-26 16:07             ` Corinna Vinschen
  2021-11-27 13:16               ` Z. Majeed
  0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2021-11-26 16:07 UTC (permalink / raw)
  To: Z. Majeed; +Cc: cygwin-developers

On Nov 26 14:33, Z. Majeed wrote:
> Good idea! I planned to combine Linux and Windows parts of the failing test to reproduce the inconsistent VmSize issue - but making use of TBB code for a cygwin feature is great - I actually needed RLIMIT_AS for this port too
> I looked at fhandler_process.cc last night - adding VmPeak seems just couple lines using Win32 PeakPagefileUsage
>  
>   On Fri, Nov 26, 2021 at 5:47 AM, Corinna Vinschen<corinna-cygwin@cygwin.com> wrote:   On Nov 25 19:51, Corinna Vinschen wrote:
> > On Nov 25 18:06, Z. Majeed wrote:
> > > Thanks for clearing that up - I'll send a patch to mingw-w64-public
> > > 
> > > The porting tip is appreciated - luckily the need for Win32 in the
> > > port has been minimal - it may be obviated completely if I can add
> > > VmPeak support - and take care of the other issue - a VmSize number
> > > that does not match Win32 PagefileUsage
> > 
> > Yeah, improving Cygwin's /proc/self/status output would be a nice
> > option as well, if you'd like to take a stab at it...?
> 
> Btw., wouldn't it be great to use your Windows limitMem function as
> template to implement getrlimit/setrlimit(RLIMIT_AS) inside Cygwin?

I took a stab at RLIMIT_AS:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3502a6ff2e27

Would you mind to take a look?


Thanks,
Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-26 16:07             ` Corinna Vinschen
@ 2021-11-27 13:16               ` Z. Majeed
  2021-11-29 10:46                 ` Corinna Vinschen
  0 siblings, 1 reply; 11+ messages in thread
From: Z. Majeed @ 2021-11-27 13:16 UTC (permalink / raw)
  To: cygwin-developers; +Cc: cygwin-developers



That was fast! Looks great - does RLIM_INFINITY need special handling? 
 
  On Fri, Nov 26, 2021 at 11:07 AM, Corinna Vinschen<corinna-cygwin@cygwin.com> wrote:   On Nov 26 14:33, Z. Majeed wrote:
> Good idea! I planned to combine Linux and Windows parts of the failing test to reproduce the inconsistent VmSize issue - but making use of TBB code for a cygwin feature is great - I actually needed RLIMIT_AS for this port too
> I looked at fhandler_process.cc last night - adding VmPeak seems just couple lines using Win32 PeakPagefileUsage
>  
>  On Fri, Nov 26, 2021 at 5:47 AM, Corinna Vinschen<corinna-cygwin@cygwin.com> wrote:  On Nov 25 19:51, Corinna Vinschen wrote:
> > On Nov 25 18:06, Z. Majeed wrote:
> > > Thanks for clearing that up - I'll send a patch to mingw-w64-public
> > > 
> > > The porting tip is appreciated - luckily the need for Win32 in the
> > > port has been minimal - it may be obviated completely if I can add
> > > VmPeak support - and take care of the other issue - a VmSize number
> > > that does not match Win32 PagefileUsage
> > 
> > Yeah, improving Cygwin's /proc/self/status output would be a nice
> > option as well, if you'd like to take a stab at it...?
> 
> Btw., wouldn't it be great to use your Windows limitMem function as
> template to implement getrlimit/setrlimit(RLIMIT_AS) inside Cygwin?

I took a stab at RLIMIT_AS:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3502a6ff2e27

Would you mind to take a look?


Thanks,
Corinna
  

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-27 13:16               ` Z. Majeed
@ 2021-11-29 10:46                 ` Corinna Vinschen
  2021-11-29 14:18                   ` Z. Majeed
  0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2021-11-29 10:46 UTC (permalink / raw)
  To: cygwin-developers

On Nov 27 13:16, Z. Majeed wrote:
> 
> 
> That was fast! Looks great

Unfortunately it doesn't work as desired.  In contrast to Linux, changing
the limit to a higher limit doesn't produce an error.  The new nested job
has just a higher limit, while the limit of the parent job is enforced.
Therefore, just adding a new nested job is not good.

Apart from tha I noticed the call order was wrong  Adding the process to
the job should only occur *after* all other calls succeeded.

> - does RLIM_INFINITY need special handling? 

I thought not and I already had written a lengthy explanation... which
I spare you with, because the code has to be rewritten anyway...


Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-29 10:46                 ` Corinna Vinschen
@ 2021-11-29 14:18                   ` Z. Majeed
  2021-11-29 14:33                     ` Z. Majeed
  0 siblings, 1 reply; 11+ messages in thread
From: Z. Majeed @ 2021-11-29 14:18 UTC (permalink / raw)
  To: cygwin-developers

Yeah - I discovered the same after building a cygwin1.dll from master - one of the TBB tests does exactly that

https://github.com/oneapi-src/oneTBB/blob/master/test/tbbmalloc/test_malloc_compliance.cpp#L1044

limitMem(200);
ReallocParam();
limitMem(0);

limitMem(0) means set rlim_cur to rlim_max

your observation about the call order is reflected in getrlimit returning a wrong value after a silent setrlimit failure

I dug deeper into setrlimit and windows job objects - here are some salient points I found in the docs

linux:

- https://man7.org/linux/man-pages/man2/setrlimit.2.html:

  - man getrlimit setrlimit
  - an unprivileged process may set only its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit
  - The value RLIM_INFINITY denotes no limit on a resource
  - RLIMIT_AS - This is the maximum size of the process's virtual memory (address space).  The limit is specified in bytes, and is rounded down to the system page size
  - A child process created via fork(2) inherits its parent's resource limits.  Resource limits are preserved across execve(2).
  - Resource limits are per-process attributes that are shared by all of the threads in a process.
  - Lowering the soft limit for a resource below the process's current consumption of that resource will succeed (but will prevent the process from further increasing its consumption of the resource).

windows:

- https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jobobject_basic_limit_information:

  - JOB_OBJECT_LIMIT_PROCESS_MEMORY flag to enable process memory limits - Causes all processes associated with the job to limit their committed memory. If the job is nested, the effective memory limit is the most restrictive memory limit in the job chain.

- https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jobobject_extended_limit_information:

  - JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure contains memory limits
  - ProcessMemoryLimit - If the LimitFlags member of the JOBOBJECT_BASIC_LIMIT_INFORMATION structure specifies the JOB_OBJECT_LIMIT_PROCESS_MEMORY value, this member specifies the limit for the virtual memory that can be committed by a process. Otherwise, this member is ignored

- https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-setinformationjobobject:

  - SetInformationJobObject function to set memory limits with a JOBOBJECT_EXTENDED_LIMIT_INFORMATION parameter
  - To establish the limits one at a time or change a subset of the limits, call the QueryInformationJobObject function to obtain the current limits, modify these limits, and then call SetInformationJobObject

- https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-queryinformationjobobject:

  - QueryInformationJobObject function to get memory limits with a JOBOBJECT_EXTENDED_LIMIT_INFORMATION parameter

- https://docs.microsoft.com/en-us/windows/win32/procthread/job-objects:

  - To associate a process with a job, use the AssignProcessToJobObject function. After a process is associated with a job, the association cannot be broken. A process can be associated with more than one job in a hierarchy of nested jobs. For more information, see Nested Jobs.
  - After a process is associated with a job, by default any child processes it creates using CreateProcess are also associated with the job
  - To determine if a process is running in a job, use the IsProcessInJob function.
  - If a process associated with a job attempts to increase its working set size or process priority from the limit established by the job, the function calls succeed but are silently ignored

- https://docs.microsoft.com/en-us/windows/win32/procthread/nested-jobs:

  - Processes in a job hierarchy are either explicitly associated with a job object using the AssignProcessToJobObject function or implicitly associated during process creation, same as for standalone jobs.
  - When processes are implicitly associated with a job during process creation, a child process is associated with every job in the job chain of its parent process
  - The effective limit for child job can be more restrictive than the limit of its parent, but it cannot be less restrictive


On Monday, November 29, 2021, 05:46:41 AM EST, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: 


On Nov 27 13:16, Z. Majeed wrote:
> 
> 
> That was fast! Looks great

Unfortunately it doesn't work as desired.  In contrast to Linux, changing
the limit to a higher limit doesn't produce an error.  The new nested job
has just a higher limit, while the limit of the parent job is enforced.
Therefore, just adding a new nested job is not good.

Apart from tha I noticed the call order was wrong  Adding the process to
the job should only occur *after* all other calls succeeded.

> - does RLIM_INFINITY need special handling? 

I thought not and I already had written a lengthy explanation... which
I spare you with, because the code has to be rewritten anyway...



Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Why is _WIN64 not defined as 1 in _cygwin.h?
  2021-11-29 14:18                   ` Z. Majeed
@ 2021-11-29 14:33                     ` Z. Majeed
  0 siblings, 0 replies; 11+ messages in thread
From: Z. Majeed @ 2021-11-29 14:33 UTC (permalink / raw)
  To: cygwin-developers

Couple more points

- https://docs.microsoft.com/en-us/windows/win32/procthread/job-objects

  - To obtain a handle for an existing job object, use the OpenJobObject function and specify the name given to the object when it was created. Only named job objects can be opened.

- https://docs.microsoft.com/en-us/windows/win32/api/jobapi/nf-jobapi-isprocessinjob

  - An application cannot obtain a handle to the job object in which it is running unless it has the name of the job object. However, an application can call the QueryInformationJobObject function with NULL to obtain information about the job object.


On Monday, November 29, 2021, 09:19:31 AM EST, Z. Majeed <zmajeed@sbcglobal.net> wrote: 


Yeah - I discovered the same after building a cygwin1.dll from master - one of the TBB tests does exactly that

https://github.com/oneapi-src/oneTBB/blob/master/test/tbbmalloc/test_malloc_compliance.cpp#L1044

limitMem(200);
ReallocParam();
limitMem(0);

limitMem(0) means set rlim_cur to rlim_max

your observation about the call order is reflected in getrlimit returning a wrong value after a silent setrlimit failure

I dug deeper into setrlimit and windows job objects - here are some salient points I found in the docs

linux:

- https://man7.org/linux/man-pages/man2/setrlimit.2.html

  - man getrlimit setrlimit
  - an unprivileged process may set only its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit
  - The value RLIM_INFINITY denotes no limit on a resource
  - RLIMIT_AS - This is the maximum size of the process's virtual memory (address space).  The limit is specified in bytes, and is rounded down to the system page size
  - A child process created via fork(2) inherits its parent's resource limits.  Resource limits are preserved across execve(2).
  - Resource limits are per-process attributes that are shared by all of the threads in a process.
  - Lowering the soft limit for a resource below the process's current consumption of that resource will succeed (but will prevent the process from further increasing its consumption of the resource).

windows:

- https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jobobject_basic_limit_information

  - JOB_OBJECT_LIMIT_PROCESS_MEMORY flag to enable process memory limits - Causes all processes associated with the job to limit their committed memory. If the job is nested, the effective memory limit is the most restrictive memory limit in the job chain.

- https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jobobject_extended_limit_information

  - JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure contains memory limits
  - ProcessMemoryLimit - If the LimitFlags member of the JOBOBJECT_BASIC_LIMIT_INFORMATION structure specifies the JOB_OBJECT_LIMIT_PROCESS_MEMORY value, this member specifies the limit for the virtual memory that can be committed by a process. Otherwise, this member is ignored

- https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-setinformationjobobject

  - SetInformationJobObject function to set memory limits with a JOBOBJECT_EXTENDED_LIMIT_INFORMATION parameter
  - To establish the limits one at a time or change a subset of the limits, call the QueryInformationJobObject function to obtain the current limits, modify these limits, and then call SetInformationJobObject

- https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-queryinformationjobobject

  - QueryInformationJobObject function to get memory limits with a JOBOBJECT_EXTENDED_LIMIT_INFORMATION parameter

- https://docs.microsoft.com/en-us/windows/win32/procthread/job-objects

  - To associate a process with a job, use the AssignProcessToJobObject function. After a process is associated with a job, the association cannot be broken. A process can be associated with more than one job in a hierarchy of nested jobs. For more information, see Nested Jobs.
  - After a process is associated with a job, by default any child processes it creates using CreateProcess are also associated with the job
  - To determine if a process is running in a job, use the IsProcessInJob function.
  - If a process associated with a job attempts to increase its working set size or process priority from the limit established by the job, the function calls succeed but are silently ignored

- https://docs.microsoft.com/en-us/windows/win32/procthread/nested-jobs

  - Processes in a job hierarchy are either explicitly associated with a job object using the AssignProcessToJobObject function or implicitly associated during process creation, same as for standalone jobs.
  - When processes are implicitly associated with a job during process creation, a child process is associated with every job in the job chain of its parent process
  - The effective limit for child job can be more restrictive than the limit of its parent, but it cannot be less restrictive


On Monday, November 29, 2021, 05:46:41 AM EST, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: 


On Nov 27 13:16, Z. Majeed wrote:
> 
> 
> That was fast! Looks great

Unfortunately it doesn't work as desired.  In contrast to Linux, changing
the limit to a higher limit doesn't produce an error.  The new nested job
has just a higher limit, while the limit of the parent job is enforced.
Therefore, just adding a new nested job is not good.

Apart from tha I noticed the call order was wrong  Adding the process to
the job should only occur *after* all other calls succeeded.

> - does RLIM_INFINITY need special handling? 

I thought not and I already had written a lengthy explanation... which
I spare you with, because the code has to be rewritten anyway...



Corinna

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-11-29 14:33 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1016746971.2414349.1637763426878.ref@mail.yahoo.com>
2021-11-24 14:17 ` Why is _WIN64 not defined as 1 in _cygwin.h? Z. Majeed
2021-11-25 13:07   ` Corinna Vinschen
2021-11-25 18:06     ` Z. Majeed
2021-11-25 18:51       ` Corinna Vinschen
2021-11-26 10:47         ` Corinna Vinschen
2021-11-26 14:33           ` Z. Majeed
2021-11-26 16:07             ` Corinna Vinschen
2021-11-27 13:16               ` Z. Majeed
2021-11-29 10:46                 ` Corinna Vinschen
2021-11-29 14:18                   ` Z. Majeed
2021-11-29 14:33                     ` Z. Majeed

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).