public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: setrlimit always fails
Date: Fri, 12 Feb 2021 11:56:12 -0700	[thread overview]
Message-ID: <5dc9c6fa-dee6-94a1-e3ee-e73eb6096047@SystematicSw.ab.ca> (raw)
In-Reply-To: <20210212091233.GG4251@calimero.vinschen.de>

On 2021-02-12 02:12, Corinna Vinschen via Cygwin wrote:
> On Feb 12 00:26, Brian Inglis wrote:
>> On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
>>> On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
>>>> I'm trying to use setrlimit to impose limits on various resources such
>>>> as CPU time and memory.  The call to setrlimit always fails.  I've
>>>> distilled this into the following example test.c:
>>> [...]
>>>>       if (setrlimit(RLIMIT_CPU,&rlim) < 0)
>>> [...]
>>>> setrlimit: Invalid argument
>>>
>>> Cygwin's setrlimit only supports a few resources, as you can see in the source:
>>>
>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201
>>
>> In that case could I suggest:
>>
>> 	/usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
>> 	https://cygwin.com/cygwin-api/compatibility.html#std-susv4
>>
>> in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml
>>
>> get/setrlimit entries should be annotated with:
> 
> https://cygwin.com/acronyms/#PGA

I'll see what I can do. Does anyone know if <ulink> is supported within 
<screen>? I seem to remember struggles updating proc(5) in specialnames.xml.

It appears that code using other than the common POSIX resources need existence 
checks.
I am unsure if it is worth adding definitions for any others.
It may be possible to implement RSS, NPROC, LOCKS, NICE, but
https://cygwin.com/acronyms/#SHDTI

Comparing Cygwin and Linux ([uapi/]asm-generic/}:

#define RLIMIT_CPU		0	/* CPU time in seconds */
#define RLIMIT_FSIZE		1	/* Maximum filesize */
#define RLIMIT_DATA		2	/* max data size */
#define RLIMIT_STACK		3	/* max stack size */
#define RLIMIT_CORE		4	/* max core file size */
#ifdef LINUX
#define RLIMIT_RSS		5	/* max resident set size */
#define RLIMIT_NPROC		6	/* max number of processes */
#define RLIMIT_NOFILE		7	/* max number of open files */
#define RLIMIT_AS		9	/* address space limit */
#else
#define RLIMIT_NOFILE		5	/* max number of open files */
#define RLIMIT_OFILE		RLIMIT_NOFILE	/* BSD name */
#define RLIMIT_AS		6	/* address space limit */
#endif
#ifdef LINUX
#define RLIMIT_LOCKS		10	/* maximum file locks held */
#define RLIMIT_SIGPENDING	11	/* max number of pending signals */
#define RLIMIT_MSGQUEUE		12	/* maximum bytes in POSIX mqueues */
#define RLIMIT_NICE		13	/* max nice prio allowed to raise to */
#define RLIMIT_RTPRIO		14	/* maximum realtime priority */
#define RLIMIT_RTTIME		15	/* timeout for RT tasks in us */
#define RLIM_NLIMITS		16
#else
#define RLIMIT_NLIMITS		7	/* upper bound of RLIMIT_* defines */
#endif

Linux man says:

"RLIMIT_MEMLOCK and RLIMIT_NPROC derive from BSD and are not specified in 
POSIX.1; they are present on the BSDs and Linux, but on few other implementations.
RLIMIT_RSS derives from BSD and is not specified in POSIX.1; it is nevertheless 
present on most implementations.
RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO,  RLIMIT_RTTIME, and 
RLIMIT_SIGPENDING are Linux-specific."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

  reply	other threads:[~2021-02-12 18:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 15:23 Patrick Chkoreff
2021-02-12  2:06 ` Ken Brown
2021-02-12  7:26   ` Brian Inglis
2021-02-12  9:12     ` Corinna Vinschen
2021-02-12 18:56       ` Brian Inglis [this message]
2021-02-12 20:38         ` Brian Inglis
2021-02-12 15:11   ` Patrick Chkoreff
2021-02-15  9:14     ` Corinna Vinschen
2021-02-15 19:54       ` Patrick Chkoreff
2021-02-15 20:48         ` Corinna Vinschen
2021-02-16 14:53           ` Patrick Chkoreff
2021-02-16 15:22             ` Marco Atzeri
2021-02-16 18:33               ` Brian Inglis
2021-02-12  9:11 ` Corinna Vinschen

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=5dc9c6fa-dee6-94a1-e3ee-e73eb6096047@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin@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).