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 until
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,
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
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), but
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 at
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't
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 launch a
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 the
user
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
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:
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 that.
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
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 points:
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
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
[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
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
[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
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-running
19 matches
Mail list logo
