Mailing List Archive: Python: Bugs

[issue7316] Add a timeout functionality to common locking operations

Index | Next | Previous | View Threaded

report at bugs

Nov 13, 2009, 9:31 AM

Post #1 of 6 (227 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations

New submission from Antoine Pitrou <pitrou [at] free>:

Here is a patch which adds a timeout feature to the locking operations
provided by Python. This feature is added at two levels:
- the C API level, with a new function PyThread_acquire_lock_timed()
- the Python level, with an optional `timeout` argument to the acquire()
method of Lock and RLock objects (it also helps simplify the wait()
function of Condition objects)

The timeout duration is expressed in microseconds at the C API level,
and in seconds at the Python API level. There is also a new Python-level
constant, `_thread.TIMEOUT_MAX`, indicating the max allowable timeout
value (values above this raise an OverflowError).

At the C level, the max timeout is PY_TIMEOUT_MAX (in microseconds). The
caller should check the value him/herself.

The patch contains both a POSIX implementation and a Windows
implementation. It still lacks docs.

----------
components: Interpreter Core, Library (Lib)
files: timedlock.patch
keywords: patch
messages: 95192
nosy: gps, pitrou
priority: normal
severity: normal
status: open
title: Add a timeout functionality to common locking operations
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15321/timedlock.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 17, 2009, 2:57 AM

Post #2 of 6 (181 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

This patch adds some docs and comments. It also adds the feature in the
non-semaphore path of thread_pthread.h, which I had forgotten to address.

----------
Added file: http://bugs.python.org/file15352/timedlock2.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 17, 2009, 8:05 AM

Post #3 of 6 (181 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations [In reply to]

Jeffrey Yasskin <jyasskin [at] gmail> added the comment:

I don't object strongly, but since locks are "supposed" to be held for
short amounts of time, a timeout shouldn't be that useful, and when
people really need it they can put it together with a condition
variable. Timeouts also interact poorly with condition variables: you
can time out the initial acquire, but if you wait on a condition there's
no place to put the timeout on the reacquire.

Given that it's hard to pick a timeout in most cases anyway, I think
it'd be a much bigger win to figure out thread interruption. (Yes, I
know that's hard, and that I promised to do it a long while ago and
never got around to it.)

That said, I have no objections at all to adding an internal timeout
ability for use by Condition.wait, and if you're still enthusiastic
about adding the timeout given the above argument, I won't block you.

----------
nosy: +jyasskin

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 17, 2009, 8:29 AM

Post #4 of 6 (179 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

> Timeouts also interact poorly with condition variables: you
> can time out the initial acquire, but if you wait on a condition there's
> no place to put the timeout on the reacquire.

I don't see how it's an objection. If you have a condition variable you
just use the cv's timeout feature, don't you? I guess there are already
tons of combinations which don't make sense anyway.

> Given that it's hard to pick a timeout in most cases anyway, I think
> it'd be a much bigger win to figure out thread interruption. (Yes, I
> know that's hard, and that I promised to do it a long while ago and
> never got around to it.)

What do you mean by thread interruption? Cancellation?

> That said, I have no objections at all to adding an internal timeout
> ability for use by Condition.wait, and if you're still enthusiastic
> about adding the timeout given the above argument, I won't block you.

Well, it's pretty basic functionality provided by the underlying OS
APIs, which is why I think it would be good to expose it. I remember
being annoyed by its absence, but it was a long time ago and I don't
remember which problem I was trying to solve.

(and it's safer than thread cancellation ;-))

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 17, 2009, 9:54 AM

Post #5 of 6 (180 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations [In reply to]

Jeffrey Yasskin <jyasskin [at] gmail> added the comment:

>> Timeouts also interact poorly with condition variables: you
>> can time out the initial acquire, but if you wait on a condition there's
>> no place to put the timeout on the reacquire.
>
> I don't see how it's an objection. If you have a condition variable you
> just use the cv's timeout feature, don't you? I guess there are already
> tons of combinations which don't make sense anyway.

The cv's timeout stops waiting for the cv to be notified, but then it
just calls acquire() with no timeout.

>> Given that it's hard to pick a timeout in most cases anyway, I think
>> it'd be a much bigger win to figure out thread interruption. (Yes, I
>> know that's hard, and that I promised to do it a long while ago and
>> never got around to it.)
>
> What do you mean by thread interruption? Cancellation?

Yes, sorry, I was using the Java term, which isn't particularly accurate.

>> That said, I have no objections at all to adding an internal timeout
>> ability for use by Condition.wait, and if you're still enthusiastic
>> about adding the timeout given the above argument, I won't block you.
>
> Well, it's pretty basic functionality provided by the underlying OS
> APIs, which is why I think it would be good to expose it. I remember
> being annoyed by its absence, but it was a long time ago and I don't
> remember which problem I was trying to solve.

Fair enough.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 20, 2009, 6:16 AM

Post #6 of 6 (162 views)
Permalink

[issue7316] Add a timeout functionality to common locking operations [In reply to]

Changes by Jesse Noller <jnoller [at] gmail>:

----------
nosy: +jnoller

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7316>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads