[Caml-list] Native Threads

[Caml-list] Native Threads

[nadji]

Hi,

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 :)
So, would it be easy to add a flag to the byte code compiler
to say that we want the full thread library ?
Or, is there a workaround to simulate Thread.kill, without
modifying the (function running as a)thread to kill (it could
be doing a long system call) ?
Or, does someone knows how to implement a function
 timeout: float -> (unit->unit) -> unit
which executes the function given in argument , but
no more than a certain amount of time, without Thread.kill ?

TIA,
Nadji

-------------------
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

Re: [Caml-list] Native Threads

[Sven LUTHER]

On Sun, Oct 06, 2002 at 01:12:47PM +0200, nadji@noos.fr wrote:
> Hi,
> 
> 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 :)

Or at least a more proeminent note on this in the documentation.
I don't think it is acceptable to have to look at the source to discover
that a documented function is just not available.

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

Re: [Caml-list] Native Threads

[Alessandro Baretta]

nadji@noos.fr wrote:
> Hi,
> Or, does someone knows how to implement a function
>  timeout: float -> (unit->unit) -> unit
> which executes the function given in argument , but
> no more than a certain amount of time, without Thread.kill ?
> 
> TIA,
> Nadji

If you want synchronous killing you're in a mess, but if I 
can live with an asynchronous model, here's how you might go 
about with it.
module type Exec_with_timeout = sig
val run : bool ref
val f : 'a -> unit
val timeout : float
end

module Finite_time_thread (M:Exec_with_timeout) = struct
let start arg =
   let kill_request () = Thread.delay M.timeout; M.run := 
false in
   let t1 = Thread.create M.f arg in
   let t2 = Thread.create kill_request () in
     Thread.join t1
end

let module Foo : Exec_with_timeout = struct
let run = ref true
let f () = while !run do () (*Your code here*) done
let timeout = 5.0 (* number of seconds this will run *)
end in
let Finite_foo_thread = Finite_time_thread Foo in
Finite_foo_thread.start ()

This requires that Foo.f work cooperatively by periodically 
checking Foo.run to verify that it still has time. When, 
upon testing Foo.run, Foo.f discovers that it has consumed 
all the allotted time, it must return.

Alex

-------------------
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

Re: [Caml-list] Native Threads

[nadji]

Alessandro Baretta wrote:

> If you want synchronous killing you're in a mess, but if I
> can live with an asynchronous model, here's how you might go
> about with it.

I can live with asynchronous killing :)

> This requires that Foo.f work cooperatively by periodically
> checking Foo.run to verify that it still has time. When,

That's what I thought. Unfortunately, not all functions can
be cooperative, and I wanted to stop a gethostbyname and
open_connection (+reads and writes) if it took too long.
I know how to do this for reads and writes, but not the others.
And I could live with the bytecode version, but I wouldn't want
to maintain 2 ocaml distributions ...

Thanks for your time,
nadji


-------------------
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

Re: [Caml-list] Native Threads

[Xavier Leroy]

> 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.  

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 :-)

- Xavier Leroy
-------------------
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

Re: [Caml-list] Native Threads

[Sven LUTHER]

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

Re: [Caml-list] Native Threads

[Stefano Zacchiroli]

On Sun, Oct 13, 2002 at 11:04:48AM +0200, Sven LUTHER wrote:
> > 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 ?

Backward compatibility, IMO we can't just remove a function from the
standard library, this has to be done in two steps:
1) deprecate it using an <h1> .. </h1> block in the HTML documentation,
   possibly in red, blinking font :-)
2) remove from the library in a next release

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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

Re: [Caml-list] Native Threads

[Sven LUTHER]

On Sun, Oct 13, 2002 at 12:42:22PM +0200, Stefano Zacchiroli wrote:
> On Sun, Oct 13, 2002 at 11:04:48AM +0200, Sven LUTHER wrote:
> > > 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 ?
> 
> Backward compatibility, IMO we can't just remove a function from the
> standard library, this has to be done in two steps:

No, I don't think this is a problem here, since the function is _not_
working on the majority of implementations out there anyway.
Maintaining backward compatibility is just maintaining backward
brokeness, which we can live with well enough.

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

Re: [Caml-list] Native Threads

[nadji]

Xavier Leroy wrote:

> 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

What if I know he doesn't :) ? But I understand this is bad engineering
practice (tough the program I wrote is 200 lines long ...).

> slightly less risky, but doesn't (currently) map well to Caml threads.

Does a standard mecanism has to ? I would be perfectly happy
with anything enabling asynchorous communication (either
sending signals, or sending exceptions, or even sending 1 kind of
message).

> So: don't kill threads.  Let them live a long and happy life :-)

How can they be happy if they have to check periodically if
they have to hara-kiri for the honor of computing ressource ? :)


-------------------
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

Re: [Caml-list] Native Threads

[Alessandro Baretta]

nadji@noos.fr wrote:

> Does a standard mecanism has to ? I would be perfectly happy
> with anything enabling asynchorous communication (either
> sending signals, or sending exceptions, or even sending 1 kind of
> message).

Did you look at the Event module of the thread library?

> 
>>So: don't kill threads.  Let them live a long and happy life :-)
> 
> 
> How can they be happy if they have to check periodically if
> they have to hara-kiri for the honor of computing ressource ? :)



Alex

-------------------
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

Re: [Caml-list] Native Threads

[nadji]

Alessandro Baretta wrote:

> Did you look at the Event module of the thread library?
>

yes, I would like _asynchronous_ messages ...
Either by signals targeted to a thread with signal handlers,
or by sending exception to a thread, wich can catch it with the
try-catch construct.
I don't know if it's easy, though.
The point is to be able to handle concurrency with small
overhead, and to be able to easily share data structures.


-------------------
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