From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic307-5.consmr.mail.bf2.yahoo.com (sonic307-5.consmr.mail.bf2.yahoo.com [74.6.134.44]) by sourceware.org (Postfix) with ESMTPS id 1113C3858421 for ; Mon, 29 Nov 2021 14:18:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1113C3858421 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sbcglobal.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sbcglobal.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1638195484; bh=yKekATs/tshg7yL90sEH3bBvTclV+tj+QYKKS8TXt8U=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=GGQmhBvk/w2Igelm3+2N5TZTcwbRpVa7ZAlAy1EcitpgClhkve3MMVDhfM+baZejKeFG2uFc9hPgaoZISYVCc3YuRiN5YvRhg8K25yYOZ6x3zN29qdwWvefDrlKcebACx3IzzVF9jAQkzSkZA0GAPr3cLXrxQP8BvYW+f6TZ5ikBp8ts7rLf9XW/e0f41HNl8rXu36uQ3KTTUqtzSyDQE5sFyQfsMqGR99bUQZnRIw52MgUydEM5QE1S1mengcstrMw+vHKw0FwKRsGDz1Mcuey8GJlMeDY6rTE9HjXZM1oLycaQ557Kz3/EJY/z9bC+jy8n+a5g+zQqjPRoEg734g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638195484; bh=2l6JIAICp1fVylMBl+PHr4iSbrhDvN4I+ar7L3GGxg+=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=EkwtnCzZnUxm8WWIDoudUs97ay2DoVH3D3ViltGAY1CayYovot/auyA8wn0FFa7HXt/s+ApKF2f4Y7SWRhF5aqknmwTv9/ZEtMsJsUQNZ56qhWAnyRLaVZ1MBkY2q0YScrZPprx65gn4IG5dRIBrwhyGtU+6qveeUOWWE7GRKxmfBZ15qUUWS+XXRgnD3Ant6JuI9vKxuLaVg0NZr1hZ9IFhs9SptCCyVmsBeOAO4+3GgEqoV4KihV0WJ2/4C/ZXT2BQ3uPRwlvMWPVBZFQ/2I84OcrbJDMpxiqAj1i13k5AD5Tq4sioMLeq8yjAkMWVmLypufC8vv2a45+fAfGmkg== X-YMail-OSG: LFkSeNYVM1msgi_JqAsz2SCEhHPhXw.S7kC4m6i0TUIVFbZhIsdsOS50n22sTm1 .BX76kz.vgKN4zWJziDWfiecbmmJvvIpNv0rYpAKw6vFSaIqqhPXSli4cntlOpc5hiLqVQUfqYnv yS2ymB2zJkaEL4iHIfKTpibhEfOcPbzQWfFM0ODJZwkOJbAxooR1JOkgWSXRICVTf9g8P0YrBNbi sbsP4basJfcL6zaH0EKQ.HLq6pD9kxKuZP2iqe9ADeOAjrCAJ_rJXLyz5AYinjKCVyVmw_tmvnce Rx5yzULZCblvq0lLCzhJcf8QBzplrLHe9uq_RpwQfJ7w32KO58hGpUugV.At6F9x12SHgqS32Wrr cNCfScW5IojM.bKr89cxMVqwGOUfWj8e9H_7dVmDqbSw2fPL6TZ3I0PuNcsiG4_KmpqsDez3bG_u ApFBuy9zTUg8grtg61UKHNMEWfPbAhSe4Dr9DtBFE9nCtodNTZIWQgCeBcBmQKeX_NyTkcIdjnHo tqyI3TYEKIKHG6qS7R086dntIJTcp3of7t7Q75vogVVT6CFRIOjqC.Q6T16tSCyVIaYX2ZaENuAp R0.f_j.5bkuzrz2R_LxOFunzENeXXXUSZ6traqdnFM5BOOk6_yZcrQN9KrYIOtA8UWpQyYwqoGPW K4DezzGI0aeuC4yz2ZkANyUnsObU4zfpnXds1J4AE5u6GEDVuwc1e29EqUuo01ioqN.85XgFP2vP gTgHbs5GxEQURIIDhUt7RZcOGzSlD.SuWMfvrYfBQhQIw0ZMOTD3rRH4wlKJPr4f376K2ZGatTqH lyjeEGdr2gFVGOi2RSi7Rl6nVRQVbnH8Feh_3s2IS.F8KM05s6a4BweJ32yMs3t5RxjTW21an8sR W7uQHyi92W8H_ilcgqIiIWbqAgzwgboXVTyCAW7tv1QOgN7y4bWKSfNQE3BZpya7vc6hJm0wy6Uc vjGEpDmuUXMn.V.AtdsujzZIs04qxPbfqVBTHOinM02.NU9p0vnPv9DJM.ArjG3fpf3L2R008c5z Zytie.bRGCdX9GvznSdXTlycUecNgBUIzbcLb_LCRN880aHvXy.6rgLAke6Wgb7KSjmqAiWrnpIv r483Z8FchtyZNdK0jZ6zvSFI9YZVjnCZKmTQAh2ce4ObjxXgSPRAwwO8BF_1j.S.XoAkCGBond8w XJbkh9TMbMK0rTH5v8lB7SsEyuz1CrbXmUXJ0zKmOwX9Rl_Et7ZPD00ABwkYRWYrcvPX6gROLa7u PLEz.GQgvLB5oTUly0l29QlzUn6VhXrj6F4BiqLpLZovbFSd96NXGwr42BwLayz2zkxzpDhUMXRz gOc_en3wY0IiHVmqCn1.JM25NVH6t9VT8A8OtpVWFsPi.J0.CSPnP6knfBDmQGHwWmOD6FEijYFR Gbx1nDKsZDaEqpZph_4jX8_89ZovfVRKhuV403A9hv31UCLV8LRGV41DGPurL_RusJR6G13WBA0R Shc7P7lExk8.iIAZvgWZxjCUTKWjldjQiXmUavY7EQb58CEG10iUSuWeMNb9jD27E4F8Md7Sft3W Z6v3EnP3g_12tyK1hXJXmsCL4i103tzrTm_cUqKD1RaGMDEdzWa5GXQ4GDle1fZ2CcIhUVGmbuWq KMXFhpoiP8_byxIb5eytnDrHdUmnVWQJ4a9NqAN2KNjlxe3vGu72QK67UYPovUI2Npw_vOwdcsvy oNOBXqdLmXKi_oJRxUZwa5Byo.a0NFrilCf9UsbeEYATvCkuXB7wq4_lyapBvDv.q33tai8uTV3n OE_AQBZRHxtFYYesdTRjZc226I4R_N9o.3xZGysV7FNlbCgboeg8r72h6vCOS65F7ZgKgo33Dcfh waHjZT0N_vvBL5UVVKCSVj0_hVoMepVWNCG4wyoQOh1ffkCGL__BDSK13BqrAik8WZMGVTghA_PQ 9aMyebl_XV21Jb50knxAonwvVMWwMXp23m1E4Zifo.AfGMCBfGSyRSXsiiYULwKwjicCKUUbEGj1 3UFpsxjQNNqYnlzTHWdaIzXCLdIvATRPYof5.4kBp.NIlFxadLUw.C4yrfkurnkWnRjKcQXzrhw_ uk2HQGDA0_qQlfiD9mFQI2h6vFhn6tDZdrXUX860vR8HdslDqBYFjSSUfwdW3u3bM63SljNymE0m RPupBukosE._x0d98ok3n3XFXMA7ev0lNlS8rEYMqP_hTDdNfhE67Zt.Al2tWnF6Lq1MmvaLiGxi _nnE9CwCYnyMFb_c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 29 Nov 2021 14:18:04 +0000 Date: Mon, 29 Nov 2021 14:18:02 +0000 (UTC) From: "Z. Majeed" To: "cygwin-developers@cygwin.com" Message-ID: <1388241945.3091122.1638195482524@mail.yahoo.com> In-Reply-To: References: <1016746971.2414349.1637763426878.ref@mail.yahoo.com> <1016746971.2414349.1637763426878@mail.yahoo.com> <743516839.2623934.1637863584991@mail.yahoo.com> <1907344113.875554.1637937234908@mail.yahoo.com> <2040290648.1078645.1638019007882@mail.yahoo.com> Subject: Re: Why is _WIN64 not defined as 1 in _cygwin.h? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.19306 YMailNorrin X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 14:18:08 -0000 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: -=C2=A0https://man7.org/linux/man-pages/man2/setrlimit.2.html: =C2=A0 - man getrlimit setrlimit =C2=A0 - 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 li= mit =C2=A0 - The value RLIM_INFINITY denotes no limit on a resource =C2=A0 - RLIMIT_AS - This is the maximum size of the process's virtual memo= ry (address space).=C2=A0 The limit is specified in bytes, and is rounded d= own to the system page size =C2=A0 - A child process created via fork(2) inherits its parent's resource= limits.=C2=A0 Resource limits are preserved across execve(2). =C2=A0 - Resource limits are per-process attributes that are shared by all = of the threads in a process. =C2=A0 - Lowering the soft limit for a resource below the process's current= consumption of that resource will succeed (but will prevent the process fr= om further increasing its consumption of the resource). windows: -=C2=A0https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jo= bobject_basic_limit_information: =C2=A0 - JOB_OBJECT_LIMIT_PROCESS_MEMORY flag to enable process memory limi= ts - Causes all processes associated with the job to limit their committed = memory. If the job is nested, the effective memory limit is the most restri= ctive memory limit in the job chain. -=C2=A0https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jo= bobject_extended_limit_information: =C2=A0 - JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure contains memory lim= its =C2=A0 - ProcessMemoryLimit - If the LimitFlags member of the JOBOBJECT_BAS= IC_LIMIT_INFORMATION structure specifies the JOB_OBJECT_LIMIT_PROCESS_MEMOR= Y value, this member specifies the limit for the virtual memory that can be= committed by a process. Otherwise, this member is ignored -=C2=A0https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi= 2-setinformationjobobject: =C2=A0 - SetInformationJobObject function to set memory limits with a JOBOB= JECT_EXTENDED_LIMIT_INFORMATION parameter =C2=A0 - To establish the limits one at a time or change a subset of the li= mits, call the QueryInformationJobObject function to obtain the current lim= its, modify these limits, and then call SetInformationJobObject -=C2=A0https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi= 2-queryinformationjobobject: =C2=A0 - QueryInformationJobObject function to get memory limits with a JOB= OBJECT_EXTENDED_LIMIT_INFORMATION parameter -=C2=A0https://docs.microsoft.com/en-us/windows/win32/procthread/job-object= s: =C2=A0 - To associate a process with a job, use the AssignProcessToJobObjec= t function. After a process is associated with a job, the association canno= t be broken. A process can be associated with more than one job in a hierar= chy of nested jobs. For more information, see Nested Jobs. =C2=A0 - After a process is associated with a job, by default any child pro= cesses it creates using CreateProcess are also associated with the job =C2=A0 - To determine if a process is running in a job, use the IsProcessIn= Job function. =C2=A0 - If a process associated with a job attempts to increase its workin= g set size or process priority from the limit established by the job, the f= unction calls succeed but are silently ignored -=C2=A0https://docs.microsoft.com/en-us/windows/win32/procthread/nested-job= s: =C2=A0 - Processes in a job hierarchy are either explicitly associated with= a job object using the AssignProcessToJobObject function or implicitly ass= ociated during process creation, same as for standalone jobs. =C2=A0 - 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 =C2=A0 - 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 wrote:=20 On Nov 27 13:16, Z. Majeed wrote: >=20 >=20 > That was fast! Looks great Unfortunately it doesn't work as desired.=C2=A0 In contrast to Linux, chang= ing the limit to a higher limit doesn't produce an error.=C2=A0 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=C2=A0 Adding the process = to the job should only occur *after* all other calls succeeded. > - does RLIM_INFINITY need special handling?=20 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