RE: [Caml-list] The best way to circumvent the lack of Thread.kill ?

RE: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[EL CHAAR Rabih SGAM/AI/SAM]

If i'm not mistaken, fork is not also implemented under windows.

Rabih

-----Message d'origine-----
De : caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]De la part de Julien Narboux
Envoyé : mercredi 2 novembre 2005 12:22
À : Richard Jones
Cc : caml-list@yquem.inria.fr
Objet : Re: [Caml-list] The best way to circumvent the lack of
Thread.kill ?


Richard Jones wrote:

>On Wed, Nov 02, 2005 at 10:52:12AM +0100, Julien Narboux wrote:
>  
>
>>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.
>>    
>>
>
>How about forking off the theorem prover as a separate process?  You
>can communicate the result back to the main program using either a
>status code or a pipe (depending on how complex the result structure
>is).  The interrupt button just kills the forked process.
>
>Rich.
>
>  
>
Yes, but the problem is that under the native windows port (see 
http://caml.inria.fr/pub/docs/manual-ocaml/manual035.html) :

"kill, pause not implemented (no inter-process signals in Windows)"


Julien Narboux

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
*************************************************************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite. 
Tout message electronique est susceptible d'alteration. 
SG Asset Management et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie.

Decouvrez l'offre et les services de SG Asset Management sur le site www.sgam.fr 

                                ********

This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited. 
E-mails are susceptible to alteration. 
Neither SG Asset Management nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. 

*************************************************************************

RE: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Igor Pechtchanski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1722 bytes --]

On Wed, 2 Nov 2005, EL CHAAR Rabih   SGAM/AI/SAM wrote:

> > -----Message d'origine-----
> > De : Julien Narboux
> > Envoyé : mercredi 2 novembre 2005 12:22
> > À : Richard Jones
> > Cc : caml-list@yquem.inria.fr
> > Objet : Re: [Caml-list] The best way to circumvent the lack of
> > Thread.kill ?
> >
> > Richard Jones wrote:
> >
> > >On Wed, Nov 02, 2005 at 10:52:12AM +0100, Julien Narboux wrote:
> > >
> > >
> > >>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.
> > >>
> > >>
> > >
> > >How about forking off the theorem prover as a separate process?  You
> > >can communicate the result back to the main program using either a
> > >status code or a pipe (depending on how complex the result structure
> > >is).  The interrupt button just kills the forked process.
> > >
> > >Rich.
> >
> > Yes, but the problem is that under the native windows port (see
> > http://caml.inria.fr/pub/docs/manual-ocaml/manual035.html) :
> >
> > "kill, pause not implemented (no inter-process signals in Windows)"
> >
> > Julien Narboux
>
> If i'm not mistaken, fork is not also implemented under windows.
>
> Rabih

It is -- only it's called CreateProcess (and has weird semantics)...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Jonathan Bryant]

That's helpful.  Anybody have any information on the second question? 
The two have to work together in my app.

It's a client/server library and I have several threads.  One simply
acepts connections and 'spawns' (not really, but) new threads.  To
control this thread I need to alternate between two blocking calls:
Unix.select and Event.sync.  I think it is rather clear why being able
to send a signal to that thread would be helpful :).  Also, there is a
pool of worker threads that will need to sleep until they are needed. 
Since my protocol is not request-response, I can't simply have the
workers alternate between Event.sync (Event.send) and Event.sync
(Event.receive) calls.

Any ideas?

On Wed, 2005-11-09 at 02:09, Matthieu Dubuget wrote:
> Jonathan Bryant a écrit :
> 
> >Ok.  Two questions.
> >
> >First of all, what is going on in the Event module?  I can't exactly get
> >it to work an I fear I'm missing some important concept.  I can't find
> >any documentation other than the interface.  Does anybody know of any
> >further documeeentation or have a good explanation of exactly what's
> >going on.
> >
> >  
> >
> 
> I asked a question related to Event usage there some time ago:
> http://groups.yahoo.com/group/ocaml_beginners/message/2968
> 
> and Rémi Vanicat answered with clean explanations:
> http://groups.yahoo.com/group/ocaml_beginners/message/2969
> 
> Maybe that will help you too?
> 
> Salutations
-- 
--Jonathan Bryant
  jtbryant@valdosta.edu
  Student Intern
  Unix System Operations
  VSU Information Technology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
("Life without music is simply an error, a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a programmer are laziness, impatience, and
hubris."
--Perl Man Page

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Richard Jones]

On Tue, Nov 08, 2005 at 03:36:15PM -0500, Jonathan Bryant wrote:
> First of all, what is going on in the Event module?  I can't exactly get
> it to work an I fear I'm missing some important concept.  I can't find
> any documentation other than the interface.  Does anybody know of any
> further documeeentation or have a good explanation of exactly what's
> going on.

Yes, the Event module is quite confusing.  I have used it in this code
(in the file adwords_mt.ml) to implement a simple command pipe between
a parent thread and worker threads, so you might want to download and
take a look at this code:

http://merjis.com/developers/adwords_api
http://merjis.com/_file/adwords-api-1.0.6.tar.gz

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Grégory Guyomarc'h]

[-- Attachment #1: Type: text/plain, Size: 5372 bytes --]

Hello,

I found these two references useful to understand the Event library:

*CML: A higher-order concurrent
language*<http://people.cs.uchicago.edu/%7Ejhr/papers/1991/pldi-cml.html>
John H. Reppy, In *ACM SGPLAN '91 Conference on Programming Language Design
and Implementation*, pages 293-305. ACM Press, 1991.
http://portal.acm.org/ft_gateway.cfm?id=113470&type=pdf

*Higher-order Concurrency*<http://people.cs.uchicago.edu/%7Ejhr/papers/1992/phd-thesis.html>
John H. Reppy, *Computer Science Technical Report 92-1285*, Cornell
University, June 1992.
http://people.cs.uchicago.edu/~jhr/papers/1992/phd-thesis.html

I think there is also a short example on how to use this module in OCaml
Oreilly book.

Hope this helps,
Gregory.

On 11/9/05, Jonathan Bryant <jtbryant@valdosta.edu> wrote:
>
> Ok. Two questions.
>
> First of all, what is going on in the Event module? I can't exactly get
> it to work an I fear I'm missing some important concept. I can't find
> any documentation other than the interface. Does anybody know of any
> further documeeentation or have a good explanation of exactly what's
> going on.
>
> Second, the Thread module allows for individual thread signal masks, but
> no way to signal specific, individual threads. It just has a way to
> signal one of them pseudo-randomly. Since the signal masks only work
> under Unix, why isn't Thread.kill mapped to pthread_kill() since that
> would allow much greater flexibility by allowing individual specific
> threads to be signaled?
>
> --Jonathan
>
> On Wed, 2005-11-02 at 13:29, David Teller wrote:
> > Let me rephrase. I don't want to kill just any thread, I want to send an
> > exception to whoever is actually synchronising on a channel. Perhaps any
> > exception can be "distantly thrown", or perhaps only one specific kind.
> > Something like
> >
> > let sender c =
> > ignore Event.sync (Event.send c 1);
> > (**Event.send passes an information,
> > while Event.sync may pass control.*)
> > ignore Event.sync (Event.send c 2);
> > ignore Event.sync (Event.send c 4);
> > ignore Event.sync (Event.kill c)
> >
> > and receiver f c =
> > f Event.sync (Event.receive c);
> > (**Event.receive receive an information,
> > while Event.sync may pass control.*)
> > f Event.sync (Event.receive c);
> > f Event.sync (Event.receive c);
> > f Event.sync (Event.receive c);
> > (*Actually, this operation throws
> > Event.Closed_channel*)
> > f Event.sync (Event.receive c)
> >
> > in
> > let c = Event.new_channel ()
> > in
> > ignore (Thread.create sender c);
> > try
> > receiver print_int c
> > with
> > x -> (*...*)
> >
> > In the case of more than two threads waiting for communication on a
> > single channel, I would say that they all should receive the exception
> > during their next Event.sync.
> >
> > I agree that this is quite close to your idea of sending thunk
> > functions, but the additional indirection strikes me as odd for
> > something which to me looks like a primitive.
> >
> > Cheers,
> > David
> >
> > Le mercredi 02 novembre 2005 à 19:43 +0100, Alessandro Baretta a écrit :
> > > David Teller wrote:
> > >
> > > > However, in my mind, all these solutions are the channel equivalent
> of
> > > > manual error-handling -- something akin to a function returning an
> ('a
> > > > option) instead of an 'a because the result None is reserved for
> errors.
> > > > I'm still slightly puzzled as to why this distant killing/raising is
> not
> > > > a core feature of channels. After all, unless I'm mistaken, channels
> are
> > > > a manner of implementing continuations. I tend to believe I should
> be
> > > > able to raise an error (a hypothetical Event.raise/Event.kill)
> instead
> > > > of returning/passing a value (as in Event.send).
> > > >
> > > > Or did I miss something ?
> > >
> > > "Channel" is maybe an inappropriate term for this strange object. An
> > > Event.channel is more like a single-slot mailbox to pass a message to
> > > someone. Any number of Threads (zero upwards) can be waiting for
> > > messages on a channel. There is no obligation that there be exactly
> one
> > > thread to kill on the other side. What would happen is try to send a
> > > hard-kill event on a channel where there is nobody on the other side?
> > > What if the there is more than one thread?
> > >
> > > You are trying to find a way around killing a thread with Thread.kill,
> > > but there is really no way to cleanly kill a thread asynchronously. A
> > > clean exit requires some cooperation from the killed thread.
> > >
> > > Alex
> --
> --Jonathan Bryant
> jtbryant@valdosta.edu
> Student Intern
> Unix System Operations
> VSU Information Technology
>
> "Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
> ("Life without music is simply an error, a pain, an exile.")
> --Frederich Nietzsche
>
> "The three cardinal values of a programmer are laziness, impatience, and
> hubris."
> --Perl Man Page
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 7586 bytes --]

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Jonathan Bryant]

Ok.  Two questions.

First of all, what is going on in the Event module?  I can't exactly get
it to work an I fear I'm missing some important concept.  I can't find
any documentation other than the interface.  Does anybody know of any
further documeeentation or have a good explanation of exactly what's
going on.

Second, the Thread module allows for individual thread signal masks, but
no way to signal specific, individual threads.  It just has a way to
signal one of them pseudo-randomly.  Since the signal masks only work
under Unix, why isn't Thread.kill mapped to pthread_kill() since that
would allow much greater flexibility by allowing individual specific
threads to be signaled?

--Jonathan

On Wed, 2005-11-02 at 13:29, David Teller wrote:
> Let me rephrase. I don't want to kill just any thread, I want to send an
> exception to whoever is actually synchronising on a channel. Perhaps any
> exception can be "distantly thrown", or perhaps only one specific kind.
> Something like
> 
>  let sender c =
>    ignore Event.sync (Event.send c 1);
>       (**Event.send passes an information,
>          while Event.sync may pass control.*)
>    ignore Event.sync (Event.send c 2);
>    ignore Event.sync (Event.send c 4);
>    ignore Event.sync (Event.kill c)
> 
>  and receiver f c =
>    f Event.sync (Event.receive c);
>        (**Event.receive receive an information,
>           while Event.sync may pass control.*)
>    f Event.sync (Event.receive c);
>    f Event.sync (Event.receive c);
>    f Event.sync (Event.receive c); 
> 	(*Actually, this operation throws 
>           Event.Closed_channel*)
>    f Event.sync (Event.receive c)
> 
>  in
>    let c = Event.new_channel ()
>    in
>      ignore (Thread.create sender c);
>      try
>        receiver print_int c
>      with
>        x -> (*...*)
> 
>  In the case of more than two threads waiting for communication on a
> single channel, I would say that they all should receive the exception
> during their next Event.sync.
> 
>  I agree that this is quite close to your idea of sending thunk
> functions, but the additional indirection strikes me as odd for
> something which to me looks like a primitive. 
> 
> Cheers,
>  David
> 
> Le mercredi 02 novembre 2005 à 19:43 +0100, Alessandro Baretta a écrit :
> > David Teller wrote:
> > 
> > >  However, in my mind, all these solutions are the channel equivalent of
> > > manual error-handling -- something akin to a function returning an ('a
> > > option) instead of an 'a because the result None is reserved for errors.
> > > I'm still slightly puzzled as to why this distant killing/raising is not
> > > a core feature of channels. After all, unless I'm mistaken, channels are
> > > a manner of implementing continuations. I tend to believe I should be
> > > able to raise an error (a hypothetical Event.raise/Event.kill) instead
> > > of returning/passing a value (as in Event.send).
> > > 
> > >  Or did I miss something ?
> > 
> > "Channel" is maybe an inappropriate term for this strange object. An 
> > Event.channel is more like a single-slot mailbox to pass a message to 
> > someone. Any number of Threads (zero upwards) can be waiting for 
> > messages on a channel. There is no obligation that there be exactly one 
> > thread to kill on the other side. What would happen is try to send a 
> > hard-kill event on a channel where there is nobody on the other side? 
> > What if the there is more than one thread?
> > 
> > You are trying to find a way around killing a thread with Thread.kill, 
> > but there is really no way to cleanly kill a thread asynchronously. A 
> > clean exit requires some cooperation from the killed thread.
> > 
> > Alex
-- 
--Jonathan Bryant
  jtbryant@valdosta.edu
  Student Intern
  Unix System Operations
  VSU Information Technology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil."
("Life without music is simply an error, a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a programmer are laziness, impatience, and
hubris."
--Perl Man Page

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Alessandro Baretta]

David Teller wrote:

>  However, in my mind, all these solutions are the channel equivalent of
> manual error-handling -- something akin to a function returning an ('a
> option) instead of an 'a because the result None is reserved for errors.
> I'm still slightly puzzled as to why this distant killing/raising is not
> a core feature of channels. After all, unless I'm mistaken, channels are
> a manner of implementing continuations. I tend to believe I should be
> able to raise an error (a hypothetical Event.raise/Event.kill) instead
> of returning/passing a value (as in Event.send).
> 
>  Or did I miss something ?

"Channel" is maybe an inappropriate term for this strange object. An 
Event.channel is more like a single-slot mailbox to pass a message to 
someone. Any number of Threads (zero upwards) can be waiting for 
messages on a channel. There is no obligation that there be exactly one 
thread to kill on the other side. What would happen is try to send a 
hard-kill event on a channel where there is nobody on the other side? 
What if the there is more than one thread?

You are trying to find a way around killing a thread with Thread.kill, 
but there is really no way to cleanly kill a thread asynchronously. A 
clean exit requires some cooperation from the killed thread.

Alex

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[David Teller]

Let me rephrase. I don't want to kill just any thread, I want to send an
exception to whoever is actually synchronising on a channel. Perhaps any
exception can be "distantly thrown", or perhaps only one specific kind.
Something like

 let sender c =
   ignore Event.sync (Event.send c 1);
      (**Event.send passes an information,
         while Event.sync may pass control.*)
   ignore Event.sync (Event.send c 2);
   ignore Event.sync (Event.send c 4);
   ignore Event.sync (Event.kill c)

 and receiver f c =
   f Event.sync (Event.receive c);
       (**Event.receive receive an information,
          while Event.sync may pass control.*)
   f Event.sync (Event.receive c);
   f Event.sync (Event.receive c);
   f Event.sync (Event.receive c); 
	(*Actually, this operation throws 
          Event.Closed_channel*)
   f Event.sync (Event.receive c)

 in
   let c = Event.new_channel ()
   in
     ignore (Thread.create sender c);
     try
       receiver print_int c
     with
       x -> (*...*)

 In the case of more than two threads waiting for communication on a
single channel, I would say that they all should receive the exception
during their next Event.sync.

 I agree that this is quite close to your idea of sending thunk
functions, but the additional indirection strikes me as odd for
something which to me looks like a primitive. 

Cheers,
 David

Le mercredi 02 novembre 2005 à 19:43 +0100, Alessandro Baretta a écrit :
> David Teller wrote:
> 
> >  However, in my mind, all these solutions are the channel equivalent of
> > manual error-handling -- something akin to a function returning an ('a
> > option) instead of an 'a because the result None is reserved for errors.
> > I'm still slightly puzzled as to why this distant killing/raising is not
> > a core feature of channels. After all, unless I'm mistaken, channels are
> > a manner of implementing continuations. I tend to believe I should be
> > able to raise an error (a hypothetical Event.raise/Event.kill) instead
> > of returning/passing a value (as in Event.send).
> > 
> >  Or did I miss something ?
> 
> "Channel" is maybe an inappropriate term for this strange object. An 
> Event.channel is more like a single-slot mailbox to pass a message to 
> someone. Any number of Threads (zero upwards) can be waiting for 
> messages on a channel. There is no obligation that there be exactly one 
> thread to kill on the other side. What would happen is try to send a 
> hard-kill event on a channel where there is nobody on the other side? 
> What if the there is more than one thread?
> 
> You are trying to find a way around killing a thread with Thread.kill, 
> but there is really no way to cleanly kill a thread asynchronously. A 
> clean exit requires some cooperation from the killed thread.
> 
> Alex
-- 
Read, Write, and Publish Standard eBooks
  Free, Open Software, Open Standards and multi-platform
    The OpenBerg project http://www.openberg.org

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[David Teller]

Thanks for the answer.

 A (unit Event.channel) or a (exn Event.channel), combined with 
(Event.poll), or perhaps a simple (bool Event.channel), would indeed
permit soft-killing a thread during a synchronization phase meant
explicitly for that purpose. A thunk computation could even generalize
this to actual communications, at the price of a somewhat strange type.

 However, in my mind, all these solutions are the channel equivalent of
manual error-handling -- something akin to a function returning an ('a
option) instead of an 'a because the result None is reserved for errors.
I'm still slightly puzzled as to why this distant killing/raising is not
a core feature of channels. After all, unless I'm mistaken, channels are
a manner of implementing continuations. I tend to believe I should be
able to raise an error (a hypothetical Event.raise/Event.kill) instead
of returning/passing a value (as in Event.send).

 Or did I miss something ?

Cheers,
 David



On Wed, 2005-11-02 at 17:24 +0100, Alessandro Baretta wrote:
> David Teller wrote:
> >  I would have figured that the best way to properly kill a thread would
> > be to have some form of channel (i.e. Events.t)-based communication
> > between threads -- and then killing the channel.
> > 
> >  Trouble is that, as I've just realized, there is no such facility as
> > killing/sending an exception through a channel. Does anyone know why ?
> 
> Event.channel is a type constructor which takes an argument identifying 
> the type of objects that are sent over the channel. You can send thunk 
> computations ((unit -> 'a) Event.channel), which may very well raise an 
> exception. Or you can simply send an exception (exn Event.channel). 
> Finally, you can send "()" on a channel (unit Event.channel), whose sole 
>   purpose is to communicate soft-kill requests.
> 
> Alex
-- 
Read, write and publish e-books,
 Free software, Open standards, Open source,
  The OpenBerg project -- http://www.openberg.org

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Alessandro Baretta]

David Teller wrote:
>  I would have figured that the best way to properly kill a thread would
> be to have some form of channel (i.e. Events.t)-based communication
> between threads -- and then killing the channel.
> 
>  Trouble is that, as I've just realized, there is no such facility as
> killing/sending an exception through a channel. Does anyone know why ?

Event.channel is a type constructor which takes an argument identifying 
the type of objects that are sent over the channel. You can send thunk 
computations ((unit -> 'a) Event.channel), which may very well raise an 
exception. Or you can simply send an exception (exn Event.channel). 
Finally, you can send "()" on a channel (unit Event.channel), whose sole 
  purpose is to communicate soft-kill requests.

Alex

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Gerd Stolpmann]

Am Mittwoch, den 02.11.2005, 15:32 +0100 schrieb Julien Narboux:
> >
> >There is a hack that works (Xavier forgive):
> >  
> >
> I just implemented your hack in drgeocaml, it works fine ! (under linux 
> at least , I have not tested on Windows yet)

I think it works under Windows, too, although not tested. The way
threads are implemented is basically the same. From reading the sources,
I only saw that under Windows Sys.sigterm is used instead of
Sys.sigvtalrm, maybe this is a special kind of joke. (Note that this
type of signal is purely virtual, i.e. not routed over the OS, so it
does not matter that Windows has no signals.)

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[David Teller]

 I would have figured that the best way to properly kill a thread would
be to have some form of channel (i.e. Events.t)-based communication
between threads -- and then killing the channel.

 Trouble is that, as I've just realized, there is no such facility as
killing/sending an exception through a channel. Does anyone know why ?

Cheers,
 David

On Wed, 2005-11-02 at 10:52 +0100, Julien Narboux wrote:
> Hi,
> 
> I just encountered the Thread.kill "not implemented" exception.

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Julien Narboux]

>
>There is a hack that works (Xavier forgive):
>  
>
I just implemented your hack in drgeocaml, it works fine ! (under linux 
at least , I have not tested on Windows yet)

Thank you very much.

Julien Narboux

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Gerd Stolpmann]

Am Mittwoch, den 02.11.2005, 14:23 +0100 schrieb Gerd Stolpmann:
> There is a hack that works (Xavier forgive):
> 
> exception User_interrupt
> 
> 
> let do_something() =
>   ignore(7 * 6)
> ;;

Just an addition: This function is too primitive for ocamlopt (it won't
check for pending events). Use

let rec do_something() =
  ignore(7 * 6); flush stdout
;;

instead.

Gerd

> 
> 
> let compute() =
>   try
>     while true do
>       do_something()
>     done;
>     assert false
>   with
>     | User_interrupt ->
> 	prerr_endline "Thread interrupted!"
> ;;
> 
> 
> let vt_signal =
>   match Sys.os_type with
>     | "Win32" -> Sys.sigterm
>     | _ -> Sys.sigvtalrm
> ;;
> 
> 
> let interrupt = ref None;;
> 
> let force_interrupt old_action_ref n =
>   (* This function is called just before the thread's timeslice ends *)
>   if Some(Thread.id(Thread.self())) = !interrupt then
>     raise User_interrupt;
>   match !old_action_ref with
>     | Sys.Signal_handle f -> f n
>     | _ -> failwith "Not in threaded mode"
> ;;
> 
> 
> let main() =
>   (* Install the signal handler: *)
>   let old_action_ref = ref Sys.Signal_ignore in
>   let old_action = 
>     Sys.signal vt_signal (Sys.Signal_handle (force_interrupt old_action_ref)) in
>   old_action_ref := old_action;
>   (* Fire up the compute thread: *)
>   let t = Thread.create compute () in
>   (* Wait for user: *)
>   print_string "Press Return: ";
>   flush stdout;
>   let _ = read_line() in
>   interrupt := Some (Thread.id t);
>   (* Wait until the thread terminates: *)
>   Thread.join t
> ;;
> 
> main();;
> 
> Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Gerd Stolpmann]

Am Mittwoch, den 02.11.2005, 10:52 +0100 schrieb Julien Narboux:
> Hi,
> 
> I just encountered the Thread.kill "not implemented" exception.

This operation is insane, better it would be removed entirely.

What could be worth of discussion is a Thread.send_exception that will
cause that a certain thread raises a certain exception the next time it
executes O'Caml code. This won't work if the thread is blocked, however.
(There is machinery to handle such asynchronous events in the O'Caml
runtime.)

For Unix (including MacOS X) you can implement send_exception yourself
by sending a signal to the thread, and defining a signal handler that
just raises an exception.

In Windows there are no signals. An extension of the O'Caml runtime
would be needed to get this behaviour.

> What is the best solution ? start a new process and use the kill at the 
> operating system level ?

Which is unavailable in Windows.

> (to make things even worse I need something which works on linux, 
> windows and macosx)

There is a hack that works (Xavier forgive):

exception User_interrupt


let do_something() =
  ignore(7 * 6)
;;


let compute() =
  try
    while true do
      do_something()
    done;
    assert false
  with
    | User_interrupt ->
	prerr_endline "Thread interrupted!"
;;


let vt_signal =
  match Sys.os_type with
    | "Win32" -> Sys.sigterm
    | _ -> Sys.sigvtalrm
;;


let interrupt = ref None;;

let force_interrupt old_action_ref n =
  (* This function is called just before the thread's timeslice ends *)
  if Some(Thread.id(Thread.self())) = !interrupt then
    raise User_interrupt;
  match !old_action_ref with
    | Sys.Signal_handle f -> f n
    | _ -> failwith "Not in threaded mode"
;;


let main() =
  (* Install the signal handler: *)
  let old_action_ref = ref Sys.Signal_ignore in
  let old_action = 
    Sys.signal vt_signal (Sys.Signal_handle (force_interrupt old_action_ref)) in
  old_action_ref := old_action;
  (* Fire up the compute thread: *)
  let t = Thread.create compute () in
  (* Wait for user: *)
  print_string "Press Return: ";
  flush stdout;
  let _ = read_line() in
  interrupt := Some (Thread.id t);
  (* Wait until the thread terminates: *)
  Thread.join t
;;

main();;

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Jacques Garrigue]

From: Julien Narboux <Julien.Narboux@inria.fr>

> >How about forking off the theorem prover as a separate process?  You
> >can communicate the result back to the main program using either a
> >status code or a pipe (depending on how complex the result structure
> >is).  The interrupt button just kills the forked process.
> >
> Yes, but the problem is that under the native windows port (see 
> http://caml.inria.fr/pub/docs/manual-ocaml/manual035.html) :
> 
> "kill, pause not implemented (no inter-process signals in Windows)"

The workaround I found a long time ago is to embed a thread in the
forked process that waits for "signals" on a pipe.

If you look at byterun/startup.c and byterun/win32.c you will
see that it is started when there is a CAMLSIGPIPE in the environment.
This is used by otherlibs/labltk/browser/shell.ml on windows.

This already works on any bytecode application.
For native code, you could just link that bit of C code, and start it
by hand.

Another way to do it, which is used by ocamlwin, is to send SIGINT
through then win32 function GenerateConsoleCtrlEvent. But this will
just interrupt, not kill. And I didn't know that function at that
time...

Jacques Garrigue

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Julien Narboux]

Jacques Garrigue wrote:

>From: Julien Narboux <Julien.Narboux@inria.fr>
>
>  
>
>>>How about forking off the theorem prover as a separate process?  You
>>>can communicate the result back to the main program using either a
>>>status code or a pipe (depending on how complex the result structure
>>>is).  The interrupt button just kills the forked process.
>>>
>>>      
>>>
>>Yes, but the problem is that under the native windows port (see 
>>http://caml.inria.fr/pub/docs/manual-ocaml/manual035.html) :
>>
>>"kill, pause not implemented (no inter-process signals in Windows)"
>>    
>>
>
>The workaround I found a long time ago is to embed a thread in the
>forked process that waits for "signals" on a pipe.
>
>If you look at byterun/startup.c and byterun/win32.c you will
>see that it is started when there is a CAMLSIGPIPE in the environment.
>This is used by otherlibs/labltk/browser/shell.ml on windows.
>
>This already works on any bytecode application.
>For native code, you could just link that bit of C code, and start it
>by hand.
>
>Another way to do it, which is used by ocamlwin, is to send SIGINT
>through then win32 function GenerateConsoleCtrlEvent. But this will
>just interrupt, not kill. And I didn't know that function at that
>time...
>
>Jacques Garrigue
>  
>
I will try that thanks a lot for your answer.

Julien Narboux

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Julien Narboux]

Richard Jones wrote:

>On Wed, Nov 02, 2005 at 10:52:12AM +0100, Julien Narboux wrote:
>  
>
>>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.
>>    
>>
>
>How about forking off the theorem prover as a separate process?  You
>can communicate the result back to the main program using either a
>status code or a pipe (depending on how complex the result structure
>is).  The interrupt button just kills the forked process.
>
>Rich.
>
>  
>
Yes, but the problem is that under the native windows port (see 
http://caml.inria.fr/pub/docs/manual-ocaml/manual035.html) :

"kill, pause not implemented (no inter-process signals in Windows)"


Julien Narboux

Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

[Richard Jones]

On Wed, Nov 02, 2005 at 10:52:12AM +0100, Julien Narboux wrote:
> 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.

How about forking off the theorem prover as a separate process?  You
can communicate the result back to the main program using either a
status code or a pipe (depending on how complex the result structure
is).  The interrupt button just kills the forked process.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com