On Wed, Sep 21, 2011 at 07:41:50AM +0200, Martin v. Loewis wrote:
> > Is it just that nobody's implemented it, or is there a good reason for
> > avoiding offering this sort of thing?
>
> I've been considering to implement killing threads several times for the
> last 15 years (I think about it once
> Is it just that nobody's implemented it, or is there a good reason for
> avoiding offering this sort of thing?
I've been considering to implement killing threads several times for the
last 15 years (I think about it once every year), and every time
I give up because it's too complex and just not
Antoon Pardon wrote:
int PyThreadState_SetAsyncExc(long id, PyObject *exc)
To prevent
naive misuse, you must write your own C extension to call this.
Not if we use ctypes! Muahahahaaa!
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Sep 20, 2011 at 8:04 AM, Ian Kelly wrote:
> "PowerCordRemoved" is not relevant here, as that would kill the entire
> process, which renders the issue of broken shared data within a
> continuing process rather moot.
>
Assuming that the "broken shared data" exists only in RAM on one
single
On Mon, Sep 19, 2011 at 12:25 AM, Chris Angelico wrote:
> On Mon, Sep 19, 2011 at 3:41 PM, Ian Kelly wrote:
>> And what if the thread gets killed in the middle of the commit?
>>
>
> Database managers solved this problem years ago. It's not done by
> preventing death until you're done - death can
On Sun, 18 Sep 2011 23:41:29 -0600, Ian Kelly wrote:
>> If the transaction object doesn't get its commit() called, it does no
>> actions at all, thus eliminating all issues of locks.
>
> And what if the thread gets killed in the middle of the commit?
The essence of a commit is that it involves a
On Sun, Sep 18, 2011 at 07:35:01AM +1000, Chris Angelico wrote:
> On Sun, Sep 18, 2011 at 5:00 AM, Nobody wrote:
> Forking a thread to discuss threads ahem.
>
> Why is it that threads can't be killed? Do Python threads correspond
> to OS-provided threads (eg POSIX threads on Linux)? Every OS
On Mon, Sep 19, 2011 at 3:41 PM, Ian Kelly wrote:
> And what if the thread gets killed in the middle of the commit?
>
Database managers solved this problem years ago. It's not done by
preventing death until you're done - death can come from someone
brutally pulling out your power cord. There's no
The point of the Java thread.stop() being deprecated seems to have very
little to do with undeclared exceptions being raised and a lot to do
with objects being left in a potentially damaged state.
As Ian said, it's a lot more complex than just adding try/catches. Killing a
thread in the middle of
Ian Kelly wrote:
And what if the thread gets killed a second time while it's in the except block?
And what if the thread gets killed in the middle of the commit?
For these kinds of reasons, any feature for raising asynchronous
exceptions in another thread would need to come with some relate
On Sat, Sep 17, 2011 at 5:38 PM, Chris Angelico wrote:
> But if it's done as an exception, all you need is to
> catch that exception and reraise it:
>
> def threadWork(lock, a1, a2, rate):
> try:
> while True:
> time.sleep(rate)
> lock.lock()
> t =
Thanks for everyone's comments - much appreciated!
Malcolm (the OP)
--
http://mail.python.org/mailman/listinfo/python-list
On 18/09/2011 00:26, Dennis Lee Bieber wrote:
On Sun, 18 Sep 2011 07:35:01 +1000, Chris Angelico
declaimed the following in gmane.comp.python.general:
Is it just that nobody's implemented it, or is there a good reason for
avoiding offering this sort of thing?
Any asynchronous "kill" r
On Sun, Sep 18, 2011 at 9:26 AM, Dennis Lee Bieber
wrote:
> def threadWork(lock, a1, a2, rate):
> while True:
> time.sleep(rate)
> lock.lock()
> t = a2.balance / 2
> a1.balance += t
> #say a thread.kill kills at this
On 9/17/2011 7:19 PM, Chris Angelico wrote:
On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebert wrote:
It's possible that the reason is analogous to why Java has deprecated
its equivalent, Thread.stop():
http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Interes
On 17Sep2011 15:27, Chris Rebert wrote:
| On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico wrote:
| > On Sun, Sep 18, 2011 at 5:00 AM, Nobody wrote:
| >> The only robust solution is to use a separate process (threads won't
| >> suffice, as they don't have a .kill() method).
| >
| > Forking a thre
On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebert wrote:
> It's possible that the reason is analogous to why Java has deprecated
> its equivalent, Thread.stop():
> http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Interesting. The main argument against having a w
On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico wrote:
> On Sun, Sep 18, 2011 at 5:00 AM, Nobody wrote:
>> The only robust solution is to use a separate process (threads won't
>> suffice, as they don't have a .kill() method).
>
> Forking a thread to discuss threads ahem.
>
> Why is it that th
On Sun, Sep 18, 2011 at 5:00 AM, Nobody wrote:
> The only robust solution is to use a separate process (threads won't
> suffice, as they don't have a .kill() method).
>
Forking a thread to discuss threads ahem.
Why is it that threads can't be killed? Do Python threads correspond
to OS-provid
On Fri, 16 Sep 2011 18:01:27 -0400, Terry Reedy wrote:
> Now, can you write that as a heuristic *algorithm*
> def dangerous_re(some_re):?
return re.search(r'\\\d', some_re) is not None
That will handle the most extreme case ;)
If the OP is serious about analysing regexps, sre_parse.pars
On 9/16/2011 9:57 AM, Nobody wrote:
I wonder if there are any
heuristics for detecting exponential time re's.
Exponential growth results from non-determinism, i.e. if there are
multiple transitions for a given character from a given state.
Common patterns include:
...(a...)?a...
On Thu, 15 Sep 2011 14:54:57 -0400, Terry Reedy wrote:
>> I was thinking there might be a technique I could use to evaluate
>> regular expressions in a thread or another process launched via
>> multiprocessing module and then kill the thread/process after a
>> specified timeout period.
>
> Only s
On Fri, Sep 16, 2011 at 4:54 AM, Terry Reedy wrote:
> On 9/15/2011 1:19 AM, pyt...@bdurham.com wrote:
>> I was thinking there might be a technique I could use to evaluate
>> regular expressions in a thread or another process launched via
>> multiprocessing module and then kill the thread/process a
On 9/15/2011 1:19 AM, pyt...@bdurham.com wrote:
Is there a way to cancel or timeout a long running regular expression?
I have a program that accepts regular expressions from users and I'm
concerned about how to handle worst case regular expressions that seem
to run forever. Ideally I'
Is there a way to cancel or timeout a long running regular
expression?
I have a program that accepts regular expressions from users and
I'm concerned about how to handle worst case regular expressions
that seem to run forever. Ideally I'm looking for a way to
evaluate a regular expr
25 matches
Mail list logo
