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 po
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 a
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
kill-thr
John Nagle 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
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, migrate
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" system}).
QNX, which is a real-time microkernel which looks like POSIX to
applications. actually got interprocess communication rig
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 2.
Hello all
I've a program that launches a lot of threads and each of them
launches a os.system("my_command").
My program also keeps a list of the launched threads, so I can make
"for" loops on the threads.
My aim is to kill everything with ctrl-C (KeyboardInterrupt).
Of course I tr
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
>
> 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
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
ads on Linux)? Every OS threading
> library I've seen has some way of killing threads, although I've not
> looked in detail into POSIX threads there (there seem to be two
> options, pthread_kill and pthread_cancel, that could be used, but I've
> not used either). If nothing
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
ethod).
| >
| > 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 threading
| > library I've seen has some way of killing threads, alth
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
ds 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 threading
> library I've seen has some way of killing threads, although I've not
> looked in detail into POSIX th
threads correspond
to OS-provided threads (eg POSIX threads on Linux)? Every OS threading
library I've seen has some way of killing threads, although I've not
looked in detail into POSIX threads there (there seem to be two
options, pthread_kill and pthread_cancel, that could be used, but I&#x
In article <685a59cd-9f02-483f-bc59-b55091a18...@u9g2000pre.googlegroups.com>,
imageguy 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 highjacking the
In article ,
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.
That's not my understanding:
http://www.
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 wrote:
>
> > > On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
> > > declaimed the following in
> > > gmane.comp.python.general:
>
> > > > In threading.
On 6 Apr, 05:25, ericwoodwo...@gmail.com wrote:
> On Apr 5, 11:07 pm, Dennis Lee Bieber wrote:
>
>
>
>
>
> > On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
> > declaimed the following in
> > gmane.comp.python.general:
>
> > > In threading.Event python 2.5 docs say;
> > > "This is one of the si
ocked on some operation
> (say a socket read without timeout), none of these solutions will work.
> That just leaves setting the threads daemonic at the start -- which
> indicates the runtime may brutally kill them when the main program
> exits.
>
You know, this bugger me a little. I k
On Apr 5, 11:07 pm, Dennis Lee Bieber wrote:
> On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
> 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 between
> > threads: one thread si
> 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
In article <53ebfff9-448f-438f-aa93-a2187bf13...@f1g2000prb.googlegroups.com>,
imageguy 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 the standard p
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:
>
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>,
>>
>> wrote:
>>
>> >I'm using queues to talk between these threads so I could certainly
>> >put
On Apr 5, 12:22 am, a...@pythoncraft.com (Aahz) wrote:
> In article <4b52f7d7-81d5-4141-9385-ee8cfb90a...@l1g2000yqk.googlegroups.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
In article <4b52f7d7-81d5-4141-9385-ee8cfb90a...@l1g2000yqk.googlegroups.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 way to do what
>I
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 stuff
class ThreadTwo(threading.Thread):
while 1:
t: 02 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 lea
> 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
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
Hello Guys,
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 app running in the backgro
I've been developing with external multi-threaded libraries recently.
I find it difficult to use the Python prompt to experiment with these
libraries because there isn't any way to just shutdown all threads and
try things again.
If I try to exit the prompt with background threads running, then
44 matches
Mail list logo
