On Jan 4, 10:53 pm, John Nagle wrote:
> There are systems where there's support designed in for thread
> abort. LISP/Scheme systems tend to support it. QNX, the real-time
> OS, has well worked out thread-abort semantics at the C level.
> (QNX has really good features for "not getting stuck"
On 1/4/2011 6:11 PM, Adam Skutt wrote:
On Jan 4, 10:12 am, Fuzzyman wrote:
This is a case that .NET (C#) handles better than Python or Java.
Nope, read the documentation for Thread.Abort() carefully.
Thread.Abort() can cause termination inside a static constructor,
which is very bad. You s
On Jan 4, 10:12 am, Fuzzyman wrote:
>
> This is a case that .NET (C#) handles better than Python or Java.
>
Nope, read the documentation for Thread.Abort() carefully.
Thread.Abort() can cause termination inside a static constructor,
which is very bad. You sure your application can cope with that
On Jan 4, 12:31 pm, Fuzzyman wrote:
> On Jan 4, 3:31 pm, Roy Smith wrote:
>
>
>
> > In article
> > <2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com>,
>
> > Fuzzyman wrote:
> > > It is unsafe to terminate an os level thread at an arbitrary point
> > > because it may be executin
On Jan 4, 3:31 pm, Roy Smith wrote:
> In article
> <2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com>,
>
> Fuzzyman wrote:
> > It is unsafe to terminate an os level thread at an arbitrary point
> > because it may be executing code in a critical section.
> > [...]
> > The standar
In article
<2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com>,
Fuzzyman wrote:
> It is unsafe to terminate an os level thread at an arbitrary point
> because it may be executing code in a critical section.
> [...]
> The standard advice is to use a flag and do manual checking t
On Jan 4, 3:12 pm, Fuzzyman wrote:
> On Dec 29 2010, 11:31 pm, gervaz wrote:
>
> > Hi all, I need to stop a threaded (using CTR+C or kill) application if
> > it runs too much or if I decide to resume the work later.
> > I come up with the following test implementation but I wanted some
> > sugges
On Dec 29 2010, 11:31 pm, gervaz wrote:
> Hi all, I need to stop a threaded (using CTR+C or kill) application if
> it runs too much or if I decide to resume the work later.
> I come up with the following test implementation but I wanted some
> suggestion from you on how I can implement what I need
On 4 Gen, 07:13, Jean-Paul Calderone
wrote:
> On Jan 3, 6:17 pm, Adam Skutt wrote:
>
> > On Jan 3, 5:24 pm, Jean-Paul Calderone
> > wrote:
>
> > > Of course. The whole point here is not about threads vs processes.
> > > It's about shared memory concurrency vs non-shared memory
> > > concurrency
On Jan 3, 6:17 pm, Adam Skutt wrote:
> On Jan 3, 5:24 pm, Jean-Paul Calderone
> wrote:
>
> > Of course. The whole point here is not about threads vs processes.
> > It's about shared memory concurrency vs non-shared memory
> > concurrency. You can implement both with threads and both with
> > pr
On Jan 3, 5:24 pm, Jean-Paul Calderone
wrote:
> Of course. The whole point here is not about threads vs processes.
> It's about shared memory concurrency vs non-shared memory
> concurrency. You can implement both with threads and both with
> processes, but threads are geared towards shared memor
On Jan 3, 5:05 pm, gervaz wrote:
> Regarding the case pointed out by Adam I think the best way to
> deal with it is to create a critical section so that the shared memory
> will be updated in an atomic fashion.
Ok, so if the OS kills the process between taking the lock and
releasing it, what are
gervaz writes:
> On 3 Gen, 22:17, Adam Skutt wrote:
>> On Jan 3, 4:06 pm, Jean-Paul Calderone
>> wrote:
>>
>>
>>
>> > > Multiple processes, ok, but then regarding processes' interruption
>> > > there will be the same problems pointed out by using threads?
>>
>> > No. Processes can be terminate
On Jan 3, 4:17 pm, Adam Skutt wrote:
> On Jan 3, 4:06 pm, Jean-Paul Calderone
> wrote:
>
>
>
> > > Multiple processes, ok, but then regarding processes' interruption
> > > there will be the same problems pointed out by using threads?
>
> > No. Processes can be terminated easily on all major plat
On 3 Gen, 22:17, Adam Skutt wrote:
> On Jan 3, 4:06 pm, Jean-Paul Calderone
> wrote:
>
>
>
> > > Multiple processes, ok, but then regarding processes' interruption
> > > there will be the same problems pointed out by using threads?
>
> > No. Processes can be terminated easily on all major platfo
On Jan 3, 4:06 pm, Jean-Paul Calderone
wrote:
>
> > Multiple processes, ok, but then regarding processes' interruption
> > there will be the same problems pointed out by using threads?
>
> No. Processes can be terminated easily on all major platforms. See
> `os.kill`.
>
Yes, but that's not the
On Jan 3, 3:22 pm, gervaz wrote:
> On 3 Gen, 17:47, de...@web.de (Diez B. Roggisch) wrote:
>
>
>
> > gervaz writes:
> > > On 31 Dic 2010, 23:25, Alice Bevan–McGregor
> > > wrote:
> > >> On 2010-12-31 10:28:26 -0800, John Nagle said:
>
> > >> > Even worse, sending control-C to a multi-thread prog
On 3 Gen, 17:47, de...@web.de (Diez B. Roggisch) wrote:
> gervaz writes:
> > On 31 Dic 2010, 23:25, Alice Bevan–McGregor
> > wrote:
> >> On 2010-12-31 10:28:26 -0800, John Nagle said:
>
> >> > Even worse, sending control-C to a multi-thread program
> >> > is unreliable in CPython. See "http://bl
gervaz writes:
> On 31 Dic 2010, 23:25, Alice Bevan–McGregor
> wrote:
>> On 2010-12-31 10:28:26 -0800, John Nagle said:
>>
>> > Even worse, sending control-C to a multi-thread program
>> > is unreliable in CPython. See "http://blip.tv/file/2232410";
>> > for why. It's painful.
>>
>> AFIK, that
gervaz wrote:
>
>Ok, but then suppose I have multiple long running threads that I want
>to delete/suspend because they are tooking too much time, which
>solution do you propose?
The right solution is to write your threads so they have an escape hatch --
to periodically check a "should I die?" fla
On 31 Dic 2010, 23:25, Alice Bevan–McGregor
wrote:
> On 2010-12-31 10:28:26 -0800, John Nagle said:
>
> > Even worse, sending control-C to a multi-thread program
> > is unreliable in CPython. See "http://blip.tv/file/2232410";
> > for why. It's painful.
>
> AFIK, that has been resolved in Python
On 2010-12-31 10:28:26 -0800, John Nagle said:
Even worse, sending control-C to a multi-thread program
is unreliable in CPython. See "http://blip.tv/file/2232410";
for why. It's painful.
AFIK, that has been resolved in Python 3.2 with the introduction of an
intelligent thread scheduler as p
On 12/29/2010 3:31 PM, gervaz wrote:
Hi all, I need to stop a threaded (using CTR+C or kill) application if
it runs too much or if I decide to resume the work later.
I come up with the following test implementation but I wanted some
suggestion from you on how I can implement what I need in a bett
23 matches
Mail list logo
