public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
From: "Z. Majeed" <zmajeed@sbcglobal.net>
To: "cygwin-developers@cygwin.com" <cygwin-developers@cygwin.com>
Subject: Re: Why is _WIN64 not defined as 1 in _cygwin.h?
Date: Mon, 29 Nov 2021 14:18:02 +0000 (UTC)	[thread overview]
Message-ID: <1388241945.3091122.1638195482524@mail.yahoo.com> (raw)
In-Reply-To: <YaSvifjCPDTdeWuk@calimero.vinschen.de>

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

  reply	other threads:[~2021-11-29 14:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1016746971.2414349.1637763426878.ref@mail.yahoo.com>
2021-11-24 14:17 ` 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 [this message]
2021-11-29 14:33                     ` Z. Majeed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1388241945.3091122.1638195482524@mail.yahoo.com \
    --to=zmajeed@sbcglobal.net \
    --cc=cygwin-developers@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).