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 =
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
18 matches
Mail list logo
