Add check for setrlimit() support

[gswagere]

BPO	551960
Nosy	@loewis
Files	test_resource.py.patch test_resource.py.patch: Revised to check for error return instead

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2002-12-12.18:14:19.000>
created_at = <Date 2002-05-03.18:18:19.000>
labels = ['tests']
title = 'Add check for setrlimit() support'
updated_at = <Date 2002-12-12.18:14:19.000>
user = 'https://bugs.python.org/gswagere'

bugs.python.org fields:

activity = <Date 2002-12-12.18:14:19.000>
actor = 'jlt63'
assignee = 'jlt63'
closed = True
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2002-05-03.18:18:19.000>
creator = 'gsw_agere'
dependencies = []
files = ['4224', '4225']
hgrepos = []
issue_num = 551960
keywords = ['patch']
message_count = 9.0
messages = ['39833', '39834', '39835', '39836', '39837', '39838', '39839', '39840', '39841']
nosy_count = 3.0
nosy_names = ['loewis', 'jlt63', 'gsw_agere']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue551960'
versions = ['Python 2.3']

[gswagere]

The new test_resource test calls resource.setrlimit()
to change the file size limits. This fails on Cygwin,
which supports setrlimit() and getrlimit(), just not
changing that particular setting. (The same would
apply to any other platforms that has those functions
but not that particular feature.)

Since that getrlimit() works, and setrlimit() can be
used for other reasons, a check for sys.platform was
added to that part of the test.

[loewis]

Logged In: YES
user_id=21627

Don't check for systems, check for features instead.

In this specific case, what error does Cygwin report? Could
that be used to deal with the missing feature in a more
general way?

[gswagere]

Logged In: YES
user_id=329402

Cygwin Python raises ValueError when you call setrlimit()
for RLIMIT_FSIZE. That limit is hardcoded at infinity and
cannot be changed. I have submitted an alternative patch
that looks for ValueError rather than checking sys.platform.

[loewis]

Logged In: YES
user_id=21627

I'm not sure I understand the logic in the modified
setrlimit(FSIZE) case. If setting the limit fails, it seems
that the entire test should be skipped. Raising TestSkipped
might be appropriate, to indicate that the result of the
test is not trustworthy.

[gswagere]

Logged In: YES
user_id=329402

Since there are other limits that can be set via setrlimit(),
failing the entire test due to a limitation on setrlimit(FSIZE)
did not seem appropriate (even though this is currently the
only resource limit that is tested).

Besides, even though setrlimit(FSIZE) isn't allowed to change
the value, it should still be able to set it to the values returned
via getrlimit(), and should still report ValueError for extremely
large values for either cur or max. So the test is meaningful
even on systems that aren't allowed to lower the FSIZE limit.

[loewis]

Logged In: YES
user_id=21627

Jason, can you please review this patch, and apply it if it
looks ok?

If not, please unassign it.

[jlt63]

Logged In: YES
user_id=86216

The patch looks OK from a Cygwin point of view. However,
I'm not very knowledgeable in this area. Still OK to apply?

[loewis]

Logged In: YES
user_id=21627

If "looks ok" means "the test fails without the patch, and
passes with the patch", then go ahead and apply it.

[jlt63]

Logged In: YES
user_id=86216

Checked in as Lib/test/test_resource.py 1.3.