On 2013-10-02 05:38, feedthetr...@gmx.de wrote:
(Hey Thunderbird has a very useful new feature. Ignore thread.)
Unfortunately, as of when I last tested it, it only works in the
newsgroup part of TB, not the mail portion of TB.
Sadly, Claws-Mail (my current mailer) doesn't have a native
On 10/2/2013 9:21 AM, Tim Chase wrote:
On 2013-10-02 05:38, feedthetr...@gmx.de wrote:
(Hey Thunderbird has a very useful new feature. Ignore thread.)
Unfortunately, as of when I last tested it, it only works in the
newsgroup part of TB, not the mail portion of TB.
One can read python-list
On 02/10/2013 23:34, Terry Reedy wrote:
On 10/2/2013 9:21 AM, Tim Chase wrote:
On 2013-10-02 05:38, feedthetr...@gmx.de wrote:
(Hey Thunderbird has a very useful new feature. Ignore thread.)
Unfortunately, as of when I last tested it, it only works in the
newsgroup part of TB, not the mail
On 1/31/2012 8:04 AM, Dennis Lee Bieber wrote:
({muse: who do we have to kill
to persuade OS designers to incorporate something like the Amiga ARexx
rexxport systemG}).
QNX, which is a real-time microkernel which looks like POSIX to
applications. actually got interprocess communication
On Fri, 03 Feb 2012 00:14:33 -0800, John Nagle wrote:
I won't even get into the appalling mess around the Global Interpreter
Lock.
You know full well that IronPython and Jython don't have a GIL. If the
GIL was as harmful as you repeatedly tell us, why haven't you, and
everyone else, migrated
John Nagle na...@animats.com writes:
QNX's message passing looks more like a subroutine call than an
I/O operation,
How do they enforce process isolation, or do they decide they don't need to?
--
http://mail.python.org/mailman/listinfo/python-list
Le 31/01/2012 17:04, Dennis Lee Bieber a écrit :
Of course, if that thread is stuck waiting for a call to os.system()
to complete, then it can not do anything...
os.system() is a rather limited, restrictive, call -- best used for
quick one-of operations. If running Python
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 every
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
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
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
On Mon, Sep 19, 2011 at 3:41 PM, Ian Kelly ian.g.ke...@gmail.com 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
On Sun, Sep 18, 2011 at 07:35:01AM +1000, Chris Angelico wrote:
On Sun, Sep 18, 2011 at 5:00 AM, Nobody nob...@nowhere.com 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
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 an
On Mon, Sep 19, 2011 at 12:25 AM, Chris Angelico ros...@gmail.com wrote:
On Mon, Sep 19, 2011 at 3:41 PM, Ian Kelly ian.g.ke...@gmail.com 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
On Tue, Sep 20, 2011 at 8:04 AM, Ian Kelly ian.g.ke...@gmail.com 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
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 Sat, Sep 17, 2011 at 5:38 PM, Chris Angelico ros...@gmail.com 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()
On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico ros...@gmail.com wrote:
On Sun, Sep 18, 2011 at 5:00 AM, Nobody nob...@nowhere.com 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
On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebert c...@rebertia.com 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
On 17Sep2011 15:27, Chris Rebert c...@rebertia.com wrote:
| On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico ros...@gmail.com wrote:
| On Sun, Sep 18, 2011 at 5:00 AM, Nobody nob...@nowhere.com wrote:
| The only robust solution is to use a separate process (threads won't
| suffice, as they don't
On 9/17/2011 7:19 PM, Chris Angelico wrote:
On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebertc...@rebertia.com wrote:
It's possible that the reason is analogous to why Java has deprecated
its equivalent, Thread.stop():
On Sun, Sep 18, 2011 at 9:26 AM, Dennis Lee Bieber
wlfr...@ix.netcom.com wrote:
def threadWork(lock, a1, a2, rate):
while True:
time.sleep(rate)
lock.lock()
t = a2.balance / 2
a1.balance += t
#say a
On 18/09/2011 00:26, Dennis Lee Bieber wrote:
On Sun, 18 Sep 2011 07:35:01 +1000, Chris Angelicoros...@gmail.com
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
On Apr 5, 9:48 pm, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Sun, 05 Apr 2009 12:54:45 +0200, Francesco Bochicchio
bock...@virgilio.it declaimed the following in
gmane.comp.python.general:
If yor threads are not set as 'deamons' using Thread.setDaemon method,
then your main program
On 6 Apr, 05:25, ericwoodwo...@gmail.com wrote:
On Apr 5, 11:07 pm, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
imageguy1...@gmail.com declaimed the following in
gmane.comp.python.general:
In threading.Event python 2.5 docs say;
On Apr 6, 3:45 am, bieff...@gmail.com wrote:
On 6 Apr, 05:25, ericwoodwo...@gmail.com wrote:
On Apr 5, 11:07 pm, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
imageguy1...@gmail.com declaimed the following in
In article d7c02cf3-e4ed-4d64-a880-44e1510ec...@f19g2000yqo.googlegroups.com,
bieff...@gmail.com wrote:
I know that killing threads is hard in any language (I'm facing now
the issue in a C++ program I'm writing at work), expecially doing in a
platform-independent way, but Java managed to do it.
In article 685a59cd-9f02-483f-bc59-b55091a18...@u9g2000pre.googlegroups.com,
imageguy imageguy1...@gmail.com wrote:
Aahz:
For more info, see the slides from my thread tutorial:
http://pythoncraft.com/OSCON2001/
Aahz, thanks for this reference and link to your presentation. At the
risk of
On Sat, 04 Apr 2009 22:45:23 -0700, ericwoodworth wrote:
On Apr 5, 12:22 am, a...@pythoncraft.com (Aahz) wrote:
In article
4b52f7d7-81d5-4141-9385-ee8cfb90a...@l1g2000yqk.googlegroups.com,
ericwoodwo...@gmail.com wrote:
I'm using queues to talk between these threads so I could certainly
On Apr 4, 10:43 pm, ericwoodwo...@gmail.com wrote:
Hi,
I'm new to python and even newer to threading and it seems as
though I'm missing something fundamental about threads. Basically I
have a program that looks like this:
class ThreadOne(threading.Thread):
while 1:
do
In article 53ebfff9-448f-438f-aa93-a2187bf13...@f1g2000prb.googlegroups.com,
imageguy imageguy1...@gmail.com wrote:
On Apr 4, 10:43=A0pm, ericwoodwo...@gmail.com wrote:
The issue that I'm having is...I don't know how to kill this app in
window.
I am not an expert either, however, I think
For more info, see the slides from my thread
tutorial:http://pythoncraft.com/OSCON2001/
--
Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/
Aahz, thanks for this reference and link to your presentation. At the
risk of highjacking the OP's question, I am bit
On Apr 5, 11:07 pm, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
imageguy1...@gmail.com declaimed the following in
gmane.comp.python.general:
In threading.Event python 2.5 docs say;
This is one of the simplest mechanisms for communication
In article 4b52f7d7-81d5-4141-9385-ee8cfb90a...@l1g2000yqk.googlegroups.com,
ericwoodwo...@gmail.com wrote:
I'm using queues to talk between these threads so I could certainly
put some kind of message on the queue that causes the threads to
commit suicide but I'm thinking there's a more built in
On Apr 5, 12:22 am, a...@pythoncraft.com (Aahz) wrote:
In article 4b52f7d7-81d5-4141-9385-ee8cfb90a...@l1g2000yqk.googlegroups.com,
ericwoodwo...@gmail.com wrote:
I'm using queues to talk between these threads so I could certainly
put some kind of message on the queue that causes the
Robert Rawlins - Think Blue wrote:
I've got an application which I've fearfully placed a couple of threads into
however when these threads are running it seems as if I try and quite the
application from the bash prompt it just seems to freeze the SSH client.
I've also seen that if I have my
You probably need to setDaemon (True) on your threads
after you've created them and before they run. That
tells the OS: don't bother waiting for these ones to
finish if the program exits. (At least I think that's
what it does; I don't use threads all that much)
Actually all it does is to
May 2007 09:05
To: python-list@python.org
Subject: Re: Killing Threads
You probably need to setDaemon (True) on your threads
after you've created them and before they run. That
tells the OS: don't bother waiting for these ones to
finish if the program exits. (At least I think that's
what it does
39 matches
Mail list logo
