Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Well, I have seen it hundreds of times on a dozen different Unices;
> it is very common. You don't always SEE the stuck process - sometimes
> the 'kill -9' causes the pid to become invisible to ps etc., and
> just occasionally it can continue to use CPU u
Nick Maclaren wrote:
> You don't always SEE the stuck process - sometimes
> the 'kill -9' causes the pid to become invisible to ps etc., and
> just occasionally it can continue to use CPU until the system is
> rebooted.
If that happens, there's a bug in the kernel. A process
killed with -9 shouldn
Nick Maclaren wrote:
> Think of updating a complex object in a multi-file database, for
> example. Interrupting half-way through leaves the database in a
> mess, but blocking interrupts while (possibly remote) file updates
> complete is asking for a hang.
Currently, threads can't be interrupted
Jon Ribbens <[EMAIL PROTECTED]> wrote:
>
> Can you elaborate on this? You can get zombie entries in the process
> table if nobody's called 'wait()' on them, and you can (extremely
> rarely) get unkillable process in 'disk-wait' state (usually due to
> hardware failure or a kernel bug, I suspect),
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Sockets, terminals etc. are stateful devices, and killing a process
> can leave them in a very unclean state. It is one of the most
> common causes of unkillable processes (the process can't go until
> its files do, and the socket is jammed).
Can you ela
Grrk. I have done this myself, and been involved in one of the VERY
few commercial projects that attempted to do it properly (IBM CEL,
the other recent one being VMS). I am afraid that there are a lot
of misapprehensions here.
Several people have said things like:
> The thing to model this on,
On 12:06 am, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Can you suggest any use-cases for thread termination which will *not*
result in a completely broken and unpredictable heap after the thread
has died?
Suppose you have a GUI and you want to launch a
long-running computation without
On 16/03/2007 1.06, Greg Ewing wrote:
>> Can you suggest any use-cases for thread termination which will *not*
>> result in a completely broken and unpredictable heap after the thread
>> has died?
>
> Suppose you have a GUI and you want to launch a
> long-running computation without blocking th
Josiah Carlson wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> Can you suggest any use-cases for thread termination which will *not*
>>> result in a completely broken and unpredictable heap after the thread
>>> has died?
>> Suppose you have a GUI and you want to
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Can you suggest any use-cases for thread termination which will *not*
> > result in a completely broken and unpredictable heap after the thread
> > has died?
>
> Suppose you have a GUI and you want to launch a
> long-run
[EMAIL PROTECTED] wrote:
> Can you suggest any use-cases for thread termination which will *not*
> result in a completely broken and unpredictable heap after the thread
> has died?
Suppose you have a GUI and you want to launch a
long-running computation without blocking the
user interface. You
Facundo Batista wrote:
> are there processors that support "reentrant" interrupts?
The PDP11 had seven priority levels for interrupts.
When an interrupt was handled, interrupts with
priorities less than or equal to the current level
were blocked, but the handler could be interrupted
by a higher p
[EMAIL PROTECTED] schrieb:
> Just in case it's not clear from the other things I've said: this is a
> terrible, terrible idea, and I am shocked that it is even being
> *considered* for inclusion in Python. As a foolish youth, I wasted many
> months trying to get a program that used Java's (then
On 04:24 pm, [EMAIL PROTECTED] wrote:
Jean-Paul Calderone schrieb:
I inferred from Martin's proposal that he
expected the thread to be able to catch the exception. Perhaps he
can
elaborate on what cleanup actions the dying thread will be allowed to
perform.
Perhaps he can. Hopefully, he ca
Martin v. Löwis wrote:
> asynchronous exceptions in a sensible way. I have to research somewhat
> more, but I think the standard solution to the problem in operating
> system (i.e. disabling interrupts at certain points, explicitly
> due to code or implicitly as a result of entering the interrupt
Jean-Paul Calderone schrieb:
>> I inferred from Martin's proposal that he
>> expected the thread to be able to catch the exception. Perhaps he can
>> elaborate on what cleanup actions the dying thread will be allowed to
>> perform.
>
> Perhaps he can. Hopefully, he can specifically address these
On Thu, 15 Mar 2007 09:41:31 -0500, [EMAIL PROTECTED] wrote:
>
>>> I just proposed to implement thread cancellation for the SoC. Is
>>> there any prior work where one could start?
>
>Jean-Paul> The outcome of some prior work, at least:
>
>Jean-Paul>
> http://java.sun.com/j2se/1.
>> I just proposed to implement thread cancellation for the SoC. Is
>> there any prior work where one could start?
Jean-Paul> The outcome of some prior work, at least:
Jean-Paul>
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
I responded to th
On Thu, 15 Mar 2007 14:34:15 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>I just proposed to implement thread cancellation for the SoC.
>Is there any prior work where one could start?
The outcome of some prior work, at least:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPri
I just proposed to implement thread cancellation for the SoC.
Is there any prior work where one could start?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
20 matches
Mail list logo
