From: Julien Narboux <Julien.Narboux@inria.fr>
To: caml-list@yquem.inria.fr
Subject: The best way to circumvent the lack of Thread.kill ?
Date: Wed, 02 Nov 2005 10:52:12 +0100 [thread overview]
Message-ID: <43688C4C.2080606@inria.fr> (raw)
Hi,
I just encountered the Thread.kill "not implemented" exception.
A google search gives me this answer from Xavier Leroy on the caml
weekly news (http://sardes.inrialpes.fr/~aschmitt/cwn/2003.05.20.html) :
"The general solution is to avoid using Thread.kill. Terminating another
thread at arbitrary times is an inherently unsafe operation: the
killed thread may be holding mutexes, for instance. There's a good
explanation of the problems in the Java documentation:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
explaining why they "deprecated" their equivalent of Thread.kill."
Here is the relevant part of this web page :
"Most uses of stop should be replaced by code that simply modifies some
variable to indicate that the target thread should stop running. The
target thread should check this variable regularly, and return from its
run method in an orderly fashion if the variable indicates that it is to
stop running. (This is the approach that JavaSoft's Tutorial has always
recommended.) To ensure prompt communication of the stop-request, the
variable must be volatile (or access to the variable must be synchronized)."
My problem is that I don't want to pollute my target thread with checks
for a variable.
Indeed, I am writing a graphical user interface for an automated theorem
prover.
I have a function f which decides if a theorem is true or not. It can
terminate quickly or take ages, and I want to have an "interrupt" button
in the graphical user interface so the user can stop the computation if
he wants to. I do not want to have GUI related code in the automated
theorem proving part of the program, it would not be clean imho.
What is the best solution ? start a new process and use the kill at the
operating system level ?
(to make things even worse I need something which works on linux,
windows and macosx)
Kindest regards.
Julien Narboux
next reply other threads:[~2005-11-02 10:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 9:52 Julien Narboux [this message]
2005-11-02 10:54 ` [Caml-list] " Richard Jones
2005-11-02 11:22 ` Julien Narboux
2005-11-02 13:00 ` Jacques Garrigue
2005-11-02 12:57 ` Julien Narboux
2005-11-02 13:23 ` Gerd Stolpmann
2005-11-02 14:00 ` Gerd Stolpmann
2005-11-02 14:32 ` Julien Narboux
2005-11-02 15:07 ` Gerd Stolpmann
2005-11-02 14:53 ` David Teller
2005-11-02 16:24 ` Alessandro Baretta
2005-11-02 17:00 ` David Teller
2005-11-02 18:43 ` Alessandro Baretta
2005-11-02 18:29 ` David Teller
2005-11-08 20:36 ` Jonathan Bryant
2005-11-09 1:18 ` Grégory Guyomarc'h
2005-11-09 12:37 ` Richard Jones
[not found] ` <4371A0A6.4010306@laposte.net>
2005-11-09 13:32 ` Jonathan Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43688C4C.2080606@inria.fr \
--to=julien.narboux@inria.fr \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox