From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: nadji@noos.fr, "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Native Threads
Date: Sun, 13 Oct 2002 11:04:48 +0200 [thread overview]
Message-ID: <20021013090448.GA1277@iliana> (raw)
In-Reply-To: <20021013104353.G13771@pauillac.inria.fr>
On Sun, Oct 13, 2002 at 10:43:53AM +0200, Xavier Leroy wrote:
> > I've just been playing with threads and I noticed at execution
> > time that Thread.kill is not implemented by the posix-compiled
> > version of the library. I used this flag because I thought that
> > it would be faster (please correct me if I'm wrong), and there
> > was no mention that Thread.kill would not be implemented.
> > By looking at the sources, I learned that the reason is
> > "problems with cleanup handlers on several platforms".
> > That's fine with me, but I would like to compile my
> > program :)
>
> The documentation should definitely be updated to mention that
> Thread.kill is not only unavailable with system threads, but also
> deprecated and definitely not advised.
Why not remove it entirelly ?
It is only confusing to have kill, but advice not to use it, and have it
only working in some conditions (caml threads) ?
> Being able to terminate any thread at any time, without cooperation
> from the thread, is extremely dangerous: what if the killed thread was
> holding mutexes? (I think this has been discussed recently on this
> list.) For this reason, thread APIs either provide a low-level "kill"
> operation and strongly adivse not to use it (Win32, Java), or they
> provide a more controlled "cancellation" mechanism (POSIX) that is
> slightly less risky, but doesn't (currently) map well to Caml threads.
>
> So: don't kill threads. Let them live a long and happy life :-)
Well, the idea is to interactively kill threads that loop forever or
something else such.
I know you adviced me to have a the thread check each time if it can
continue living, and stop if it is told not so, and this is what i will
be doind, but what about having a thread function available in the
thread library that does this in a somewhat standardized way ?
Friendly,
Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-10-13 8:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-06 11:12 nadji
2002-10-06 11:35 ` Sven LUTHER
2002-10-06 14:34 ` Alessandro Baretta
2002-10-06 15:02 ` nadji
2002-10-13 8:43 ` Xavier Leroy
2002-10-13 9:04 ` Sven LUTHER [this message]
2002-10-13 10:42 ` Stefano Zacchiroli
2002-10-13 11:26 ` Sven LUTHER
2002-10-13 10:45 ` nadji
2002-10-13 15:21 ` Alessandro Baretta
2002-10-13 15:26 ` nadji
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=20021013090448.GA1277@iliana \
--to=luther@dpt-info.u-strasbg.fr \
--cc=caml-list@inria.fr \
--cc=nadji@noos.fr \
--cc=xavier.leroy@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;
as well as URLs for NNTP newsgroup(s).