Alessandro Baretta | 1 Oct 2002 09:51

Re: Re: Kinds of threads


Michaël Grünewald wrote:
> Alessandro Baretta <alex <at> baretta.com> writes:
> 
> 
>>The docs say that there are two kinds of threads in O'Caml: Ocaml
>>bytecode threads and POSIX threads, and that it is possible to select
>>which implementation to use at compiler build time. Two questions:
>>first, what is the implementation chosen in the ocaml RPM distribution;
>>second, why must one choose one implementation at compiler build time?
>>Why not use a compiler switch such as --posix-threads as opposed to
>>--caml-threads?
> 
> 
> Depending of the platform, POSIX threads may not or badly
> available. Emulation can be set up, either by coercing existing thread
> capabilities to the POSIX interface, or by implementing a POSIX thread
> library, using processes and interprocesses communications to do the job (i
> have been told it was the way with linux, please confirm or infirm it).

I don't really know what you mean by "emulation", but, yes, 
LinuxThreads is POSIX-compliant extension to glibc which 
instantiates kernel-level processes.

> Maybe the switch is here because it is better to use POSIX threads when they
> are well supported by the system (e.g. BSDs); but the caml thread emulation
> may give better results in (some) other cases.

Caml threads are probably the only way to go on Windows, 
since the Win32 API is not POSIX compliant.
(Continue reading)

Remi VANICAT | 1 Oct 2002 09:52
Picon
Picon

Re: Re: Kinds of threads

Alessandro Baretta <alex <at> baretta.com> writes:

> Still, this does not answer my question: what is the threading style
> chosen for the official RPM distribution of O'Caml? Let me see if I
> can figure this out by myself...
>

One easy way to find out is to try to run a multi-threaded application
compiled to native code.
--

-- 
Rémi Vanicat
vanicat <at> labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
To unsubscribe, mail caml-list-request <at> 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

Xavier Leroy | 1 Oct 2002 11:12
Picon
Picon
Favicon

Re: Re: Kinds of threads

> The docs say that there are two kinds of threads in O'Caml: 
> Ocaml bytecode threads and POSIX threads, and that it is 
> possible to select which implementation to use at compiler 
> build time. Two questions: first, what is the implementation 
> chosen in the ocaml RPM distribution

The RPMs distributed by INRIA use bytecode threads.  That might not be
true of RPMs and Debian packages built by third parties.

> second, why must one choose one implementation at compiler build
> time? Why not use a compiler switch such as --posix-threads as opposed
> to --caml-threads?

Mostly because the idea didn't cross my mind.  Offhand, I believe that
just playing with the search path would suffice to select between the
two implementations.  (This needs to be checked, though.)

> Caml threads are probably the only way to go on Windows, 
> since the Win32 API is not POSIX compliant.

Amusingly, it's the other way around: bytecode threads use a lot of
Unix-specific hacks to get non-blocking I/O, while system threads can
easily be built on top of Win32 threads (even though the latter aren't
POSIX-compliant).

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request <at> 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
(Continue reading)

Xavier Leroy | 1 Oct 2002 11:20
Picon
Picon
Favicon

Re: beginner's questions

>   jumptbl.h is generated from existing files.  I made it "by hand":
> cd byterun && make -f Makefile.nt jumptbl.h
>   before running "make world".

Right, I believe this is a small bug in the 3.06 distribution
(the file byterun/.depend.nt should be in the distributed sources, but
isn't).

>   But real problems begin further, at Dynlink module (generally at first
> module when exception End_of_file needs to be got from stdlib.cma).
> I can't cite the exact error message, but ocamlc can't find "End_of_file"
> exception in "stdlib.cma(Pervasives)".
>   Really, any small test program, which requires End_of_file, can't be
> compiled, and the problem is not in bad paths to library/compiler.

Probably the file bytecomp/runtimedef.ml was generated incorrectly,
maybe because you didn't use the correct version of "sed".  The
Win32 Makefiles are known to work with GNU sed as found in Cygwin, but
one user reported problems with another version of sed coming from
another Windows port of Unix tools.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request <at> 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

Benjamin Monate | 1 Oct 2002 11:13
Picon

Re: Re: Kinds of threads

On Tue, 01 Oct 2002 09:51:08 +0200
Alessandro Baretta <alex <at> baretta.com> wrote:
> Still, this does not answer my question: what is the 
> threading style chosen for the official RPM distribution of 
> O'Caml? Let me see if I can figure this out by myself...
> 

Here is a small test to detect what kind of threads you have:

====================================================================
(* Compile with ocamlc -o threadtest -thread unix.cma threads.cma
threadtest.ml *) open Thread
let f () = while true do () done 
let i = create f () 
let _ = 
  try 
    kill i;
    print_string "Bytecode threads available\n"
  with Invalid_argument "Thread.kill: not implemented" 
      -> print_string "Native threads available\n"
====================================================================

Hope this helps.

--

-- 
| Benjamin Monate         | mailto:monate <at> lix.polytechnique.fr |
| LIX                     | http://www.lri.fr/~monate/         |
| École Polytechnique -  91128 Palaiseau Cedex - France        |
-------------------
To unsubscribe, mail caml-list-request <at> inria.fr Archives: http://caml.inria.fr
(Continue reading)

Xavier Leroy | 1 Oct 2002 11:44
Picon
Picon
Favicon

Re: float tuples as double_arrays?

> The floats in an all-float tuple are boxed, unlike floats in all-float 
> records.  The latter are treated as float arrays internally and have 
> double_array_tag.  I'm wondering why the former aren't treated the same 
> way?  Complexity in the compiler and not wanting the double_array special 
> case code to metastasize more is a perfectly valid answer.

I agree with the answer you suggest :-)

Another reason is that, unlike records statically declared with
"float" fields only, tuples can be used polymorphically: a float *
float can be passed to a function expecting an 'a * 'b.  This would
require run-time tests in polymorphic functions operating over tuples.

Similar tests are already generated for polymorphic functions
operating on arrays, but the tests for tuples would be more complex
because tuples, unlike arrays, are not homogeneous: one run-time test
on one component doesn't suffice to determine the type of all other
components.

> The only reason I ask is that the unboxed rep is more efficient, and tuples 
> are more convenient for some things, like breaking things out with patterns:
> [...]
> or with a record
> let {x=x;y=y;z=z;} = v in
> (* need the module name on the field above if not opened, etc. *)

This is true.  Despite this, I still recommend the use of records,
even if they are syntactically a bit heavier than tuples: you get the
"dot notation" (e.g. v.x, v.y, v.z in your example above), and finer
type distinctions if you need them (e.g. you might want to have
(Continue reading)

Xavier Leroy | 1 Oct 2002 11:57
Picon
Picon
Favicon

Re: Ocaml 3.06 bug

> There is a bug in the Unix library, which makes my program exit with
> no warning message.
> 
> It happens when I call Unix.write two times on a descriptor closed
> by the other side.

It's not an OCaml bug, it's a Unix feature.  Writes on a socket that
corresponds to a closed connection generates a SIGPIPE signal, whose
default effect is to kill your process.  

There are ways to catch SIGPIPE or to replace it by an error code
generated by Unix.write; please consult a Unix programming guide
(e.g. Steven's books).

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request <at> 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

Xavier Leroy | 1 Oct 2002 13:37
Picon
Picon
Favicon

Re: Design advice

Dan Schmidt wrote:

> One has to do with making the equivalent of an enum in C.  Say I'm
> implementing a deck of cards for a card game.  There are four suits,
> and none of them have any special properties (this isn't a game like
> bridge where different suits are treated differently).  I could do
>   type suit = Spades | Hearts | Diamonds | Clubs
> but this seems a little heavyweight; it seems weird to perform pattern
> matching on values that really have no semantic importance other than
> the fact that they are different from each other.  It's not like I'm
> going to have any code that does one thing when given the 3 of Spades
> and another thing when given the 3 of Hearts.  The other issue is that
> it is mildly annoying to, for example, write a compare function to be
> used inside a struct that implements the OrderedType signature (e.g.,
> if I want to have a Set of cards).

As others mentioned, the generic comparison functions (=, <, compare,
etc) work just fine on datatypes, and provide you with a suitable
ordering function for sets or maps.

> Finally, is there any type in the library that functions like an
> immutable array?  I would like to have an indexable bunch of values
> but use it in a purely functional way.

You can use maps (module Map from the standard library), using
integers as keys.  

> I could always just use
> Arrays and copy them before updating, but if there's already an
> idiomatic type to use I'd prefer to use that.
(Continue reading)

Will Benton | 1 Oct 2002 15:56
Picon
Favicon

any non-X GUI libraries for Mac OS X?

Hello,

I'm happily hacking on a new Mac (made the "switch" from Linux), and 
was wondering if anyone had made any non-X11 GUI libraries for OCaml 
under OS X?  It does seem like it would be a huge pain to wrap ObjC in 
a language with a type system, so I'm not optimistic -- but I'd be 
interested to hear of any developments.

cheers,
wb

-------------------
To unsubscribe, mail caml-list-request <at> 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

Thaddeus L. Olczyk | 1 Oct 2002 18:53
Picon

Re: Ocaml 3.06 bug

On Tue, 01 Oct 2002 11:57:28 +0200, Xavier Leroy
<xavier.leroy <at> inria.fr> wrote:

>> There is a bug in the Unix library, which makes my program exit with
>> no warning message.
>> 
>> It happens when I call Unix.write two times on a descriptor closed
>> by the other side.
>
>It's not an OCaml bug, it's a Unix feature.  Writes on a socket that
>corresponds to a closed connection generates a SIGPIPE signal, whose
>default effect is to kill your process.  
>
>There are ways to catch SIGPIPE or to replace it by an error code
>generated by Unix.write; please consult a Unix programming guide
>(e.g. Steven's books).
>
You are begging the question.
Reading Stevens won't help much if you don't know how signals are
handled in OCaml.
-------------------
To unsubscribe, mail caml-list-request <at> 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


Gmane