Threads Library

Threads Library

[David McClain]

I just received a copy of Reppy's new book on "Concurrent ML". I was
delighted to find that the OCAML Threads library incorporates much of his
work with channels and events.

However, unlike CML, (on Windows/NT at least) the GC does not discard
threads hung up on channels that are no longer in use by active threads.
Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
experiments generated thousands of threads before I had to kill off the
program).

Secondly, it would appear that the semantics of "with_abort" require that
the wrapper function be called ahead of all "with" functions. But
experiments where a with-function raises an exception bypass the actions of
pending "with_abort" functions on non-selected channels. So evidently, one
should not permit the use of uncaught exceptions inside of "with" functions.

Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
about the use of indefinite recursion triggered by a with-function. It would
seem that one should treat composite event lists in much the same manner as
"try-with" when it comes to recursion inside a try (resp. with) clause.
Instead of tail calling from the "with" clause one should return a value to
the outer level of the "sync" or "select", and then "match" on that value
before recursing.

I have implemented a module that provides thread safety, as long as the
above protocols are followed. In effect all events generated by Event.send
and Event.receive are first wrapped in a "with_abort" where the function
spawns a thread to respond to the eventual conjugate operation on the
channel. There are unsafe versions that simply repeat Event.send and
Event.receive for use when it is known that the corresponding thread will
not be ignored forever.

Do I understand the OCAML situation properly?

TIA

David McClain,
Sr. Scientist
Raytheon Systems Co.
Tucson, AZ

Re: Threads Library

[Xavier Leroy]

> However, unlike CML, (on Windows/NT at least) the GC does not discard
> threads hung up on channels that are no longer in use by active threads.
> Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
> experiments generated thousands of threads before I had to kill off the
> program).

This is correct.  Currently, there is no automatic reclaimation of
threads whose identifier (the associated Thread.t value) is
unreachable, because those threads could be "daemon" threads that do
useful work in the background.

> Secondly, it would appear that the semantics of "with_abort" require that
> the wrapper function be called ahead of all "with" functions. But
> experiments where a with-function raises an exception bypass the actions of
> pending "with_abort" functions on non-selected channels. So evidently, one
> should not permit the use of uncaught exceptions inside of "with" functions.
> 
> Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
> about the use of indefinite recursion triggered by a with-function. It would
> seem that one should treat composite event lists in much the same manner as
> "try-with" when it comes to recursion inside a try (resp. with) clause.
> Instead of tail calling from the "with" clause one should return a value to
> the outer level of the "sync" or "select", and then "match" on that value
> before recursing.

I haven't read Reppy's book yet, so I'm not absolutely sure I follow
you here, but generally speaking it is true that the "with_abort"
mechanism is more heavyweight in OCaml than in CML, because it is
implemented with "real" threads in OCaml while CML uses a much more
lightweight callcc-based implementation.

- Xavier Leroy

Dynamic loading and building of shared libraries

[skaller]

I have a need to load sets of ocaml functions at run time
in Viper using dlopen: this requirement arises from Python's
ability to dynamically load C extension modules: Viper
emulates this by loading text files which provide
equivalent functionality, but these files must use
native functions to provide the functionality.

At the moment, these functions must be statically
linked into the interpreter, which is not really acceptable.

It should be easy to provide a C factory function in a shared
library that returns a table of functions: my question is,
how to tell ocaml to link a shared library, rather than
a main executable.

How do I do this? If not, can a way be devised to tell
ocamlopt to do it? Or is there a reasone it isn't possible?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller

Re: Dynamic loading and building of shared libraries

[Ian Zimmerman]

>>>>> "skaller" == skaller  <skaller@maxtal.com.au> writes:

skaller> my question is, how to tell ocaml to link a shared library,
skaller> rather than a main executable.  How do I do this? If not, can
skaller> a way be devised to tell ocamlopt to do it? Or is there a
skaller> reasone it isn't possible?

I would try something like (if gcc is your C compiler)

ocamlopt -ccopt -shared -o foobar.so foo.cmx bar.cmx

It might even work; totally untested, though, of course.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
In his own soul a man bears the source
from which he draws all his sorrows and his joys.
Sophocles.

Dynamic loading and building of shared libraries

[STARYNKEVITCH Basile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1537 bytes --]

>>>>> "skaller" == skaller  <skaller@maxtal.com.au> writes:

    skaller> I have a need to load sets of ocaml functions at run time
    skaller> in Viper using dlopen [...]

    skaller> At the moment, these functions must be statically linked
    skaller> into the interpreter, which is not really acceptable.

    skaller> It should be easy to provide a C factory function in a
    skaller> shared library that returns a table of functions: my
    skaller> question is, how to tell ocaml to link a shared library,
    skaller> rather than a main executable.

    skaller> How do I do this? If not, can a way be devised to tell
    skaller> ocamlopt to do it? Or is there a reasone it isn't
    skaller> possible?

Dynamically loaded shared objects are usually made with position
independent code. This requires that the ocamlopt code generator
follows some (perhaps tricky) coding conventions (which might also
require some changes in the runtime GC system)

I agree with John Skaller that dynamic library support in ocamlopt
would be nice.

Regards

N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique 
DTA/LETI/DEIN/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX * France
phone: 1,69.08.60.55; fax: 1.69.08.83.95 home: 1,46.65.45.53
email: Basile point Starynkevitch at cea point fr 

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: Threads Library

[Juergen Pfitzenmaier]

Xavier Leroy wrote:
> This is correct.  Currently, there is no automatic reclaimation of
> threads whose identifier (the associated Thread.t value) is
> unreachable, because those threads could be "daemon" threads that do
> useful work in the background.

Why not use a special instance of Thread for daemon threads and reclaim
only all normal uses of Thread that became unreachable ?

pfitzen