Threads library

Threads library

[Ernesto Posse]

  Hi. I have a problem with the threads library. Basically I am unable to
access the library.

  The libraries are installed in the default location
(/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
2.6.4-54.5-smp on i686, running SuSE)

  I have the problem when I run the normal toplevel and a customized
toplevel.

  On the normal toplevel, I first try to do

  #load "/usr/local/lib/ocaml/threads/threads.cma";;

which complains about Unix being undefined, so I do

  #load "/usr/local/lib/ocaml/unix.cma";;

but then if I try

  Thread.create;;

it tells me it the value is unbound.

  If I try

open Thread

it tells me "Unbound module Thread".

  If I try the VM threads by doing:

#load "/usr/local/lib/ocaml/vmthreads/threads.cma";;

it complains about a conflict of interface with the normal Threads, and
then it ends the toplevel with

# Fatal error: exception Sys_blocked_io

  I get the same error even if I load the VM threads without loading the
other Thread module.

  I get exactly the same results if I make a customized toplevel as in:

ocamlmktop -thread -custom -o threadtop unix.cma threads.cma -cclib -lunix
-cclib -lthreads



  What am I doing wrong?


  Thanks



-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Threads library

[John Prevost]

On Mon, 22 Nov 2004 16:20:31 -0500 (EST), Ernesto Posse
<eposse@cs.mcgill.ca> wrote:
>   Hi. I have a problem with the threads library. Basically I am unable to
> access the library.
> 
>   The libraries are installed in the default location
> (/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
> 2.6.4-54.5-smp on i686, running SuSE)
  {...}

There are two things that will help you here.  The first is that you
want to run your toplevel like this:

ocaml -I +threads

in order to make sure that the threading libraries (and more
importantly, the thread interfaces!) are on the ocaml include path. 
This is *the* most important point, since when you try to refer to the
Threads module, the toplevel is going to look in its path to find the
.mli files, regardless of what has been linked in.

The second thing is that the order in which you #load is relevant.  If you do:

#load "threads.cma";;
#load "unix.cma";;

threads isn't actually loaded--it failed to load.  I suspect you
figured that part out, however.

So, if you just do the -I +threads and then #load "threads.cma"
instead of #load ".../lib/ocaml/threads.cma", you'll succeed for the
normal toplevel.  And with the custom toplevel, you'll still need to
include -I +threads.  You can also use:

#directory "+threads";;

to add to the include path of a running ocaml process.

And as a final note, if you have installed findlib, you can either
make a toplevel with topfind compiled in, or:

#use "topfind";;

in order to get the findlib toplevel extensions.  This will let you do:

#thread;;

to enable threading.  (It adds +threads to the include path, then
loads unix and threads.)

Hope this helps!

John.

Re: [Caml-list] Threads library

[Ernesto Posse]

  Thanks John. It worked.

  I do have another question, and it is about the behaviour of Thread.join.

  I have the following definitions:

open Thread;;

let rec f = function 0 -> () | n -> print_int n; f(n-1);;

let pp (x, y) = (create f x, create f y);;

let ppp = create pp;;

let jpp x y = join(ppp (x,y));

  I would expect that invoking

jpp 8 9;;

  would force the prompt to appear after all threads from ppp(x,y) have
ended, but this doesn't appear to be the case. If I understand
correctly, the join affects only the thread created by ppp, but not
those spawned from it. Is there a simple way to join the rest of the
threads created?



> On Mon, 22 Nov 2004 16:20:31 -0500 (EST), Ernesto Posse
> <eposse@cs.mcgill.ca> wrote:
>>   Hi. I have a problem with the threads library. Basically I am unable
>> to
>> access the library.
>>
>>   The libraries are installed in the default location
>> (/usr/local/lib/ocaml) (I installed version 3.08.1, on linux
>> 2.6.4-54.5-smp on i686, running SuSE)
>   {...}
>
> There are two things that will help you here.  The first is that you
> want to run your toplevel like this:
>
> ocaml -I +threads
>
> in order to make sure that the threading libraries (and more
> importantly, the thread interfaces!) are on the ocaml include path.
> This is *the* most important point, since when you try to refer to the
> Threads module, the toplevel is going to look in its path to find the
> .mli files, regardless of what has been linked in.
>
> The second thing is that the order in which you #load is relevant.  If you
> do:
>
> #load "threads.cma";;
> #load "unix.cma";;
>
> threads isn't actually loaded--it failed to load.  I suspect you
> figured that part out, however.
>
> So, if you just do the -I +threads and then #load "threads.cma"
> instead of #load ".../lib/ocaml/threads.cma", you'll succeed for the
> normal toplevel.  And with the custom toplevel, you'll still need to
> include -I +threads.  You can also use:
>
> #directory "+threads";;
>
> to add to the include path of a running ocaml process.
>
> And as a final note, if you have installed findlib, you can either
> make a toplevel with topfind compiled in, or:
>
> #use "topfind";;
>
> in order to get the findlib toplevel extensions.  This will let you do:
>
> #thread;;
>
> to enable threading.  (It adds +threads to the include path, then
> loads unix and threads.)
>
> Hope this helps!
>
> John.
>
>


-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Threads library

[John Prevost]

On Tue, 23 Nov 2004 11:32:50 -0500 (EST), Ernesto Posse
<eposse@cs.mcgill.ca> wrote:
> If I understand
> correctly, the join affects only the thread created by ppp, but not
> those spawned from it. Is there a simple way to join the rest of the
> threads created?

The behavior of Thread.join is specifically to wait for that specific
thread to finish running.  Since your thread ppp simply creates two
other threads and then stops, joining with it waits until those two
threads have been created.  If you want to wait for all of the created
threads to complete, you'll need to do one of a handful of things:

1) The easiest solution is to have your function pp wait until all of
the threads it creates are complete before it exits.  For example:

let pp (x, y) =
  let a = create f x in
  let b = create f y in
  begin
    join a;
    join b
  end

This isn't very extensible, but it's simple, and it works.  The main
lack of flexibility is that the function pp always waits for its
threads to complete, and sometimes you might just want to wait for all
of its subthreads to be created instead.

2) Another solution, which is mostly the same, is to have pp return
the threads it created, and let ppp decide what to do with them.  It's
probably better to change pp to return a list so that this is
extensible to more than two threads:

let pp (x, y) = [create f x; create f y]

let ppp (x, y) =
  create (fun () ->
    let subthreads = pp (x, y) in
    List.iter join subthreads)

This has the advantage that the calling function (ppp) gets to decide
whether to join with the subthreads or with the thread that creates
the subthreads.  It's still on the messy side--particularly because
everybody needs to know what threads go together.

3) You can create a pretty simple module that provides a way to group
threads together, by using the above List.iter technique.  This would
be more complicated, because a general solution needs to deal with
synchronization if multiple threads are creating threads in the
threadgroup, etc.  (I'm actually somewhat surprised that there's not
such a module already in the standard library.)  This would have the
advantage that everything could work the same way, and you can always
choose whether to join to an individual thread or to an entire
threadgroup.  I could whip something like this up later today,
although my first implementation was *too* naive, so I'm not including
it here.  :)

John.