[Caml-list] suggestion for record pattern matching and construction

[Caml-list] suggestion for record pattern matching and construction

[Eric C. Cooper]

I find that I am often writing code like
    { field1 = field1; field2 = field2; field3 = field3 }
when matching and constructing records.  I guess it's because thinking
up good names for the record fields is nontrivial and having similar
but different names for the bindings just bothers me.

How about allowing syntax like that used for labels:
    { ~field1; ~field2; ~field3 }
would expand into the above, in both pattern matching and construction
contexts.

This is orthogonal to (and I think much simpler than) omitting some
fields via "..." notation.

-- 
Eric C. Cooper          e c c @ c m u . e d u

-------------------
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] suggestion for record pattern matching and construction

[Olivier Andrieu]

 Eric C. Cooper [Wednesday 10 September 2003] :
 >
 > I find that I am often writing code like
 >     { field1 = field1; field2 = field2; field3 = field3 }
 > when matching and constructing records.  I guess it's because thinking
 > up good names for the record fields is nontrivial and having similar
 > but different names for the bindings just bothers me.
 > 
 > How about allowing syntax like that used for labels:
 >     { ~field1; ~field2; ~field3 }
 > would expand into the above, in both pattern matching and construction
 > contexts.

I have a camlp4 extension that does exactly this (well, without 
the ~). Also, you can put the module path before the { instead of
having to repeat it for each field. So :

  Mod1.Mod2.{ field1; field2 } 

is expanded into

  { Mod1.Mod2.field1 = field1 ; Mod1.Mod2.field2 = field2 }

http://oandrieu.nerim.net/ocaml/index.xhtml#pa_records

-- 
   Olivier

-------------------
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] suggestion for record pattern matching and construction

[brogoff]

On Thu, 11 Sep 2003, Olivier Andrieu wrote:
>  Eric C. Cooper [Wednesday 10 September 2003] :
>  >
>  > I find that I am often writing code like
>  >     { field1 = field1; field2 = field2; field3 = field3 }
>  > when matching and constructing records.  I guess it's because thinking
>  > up good names for the record fields is nontrivial and having similar
>  > but different names for the bindings just bothers me.
>  > 
>  > How about allowing syntax like that used for labels:
>  >     { ~field1; ~field2; ~field3 }
>  > would expand into the above, in both pattern matching and construction
>  > contexts.
> 
> I have a camlp4 extension that does exactly this (well, without 
> the ~). Also, you can put the module path before the { instead of
> having to repeat it for each field. So :
> 
>   Mod1.Mod2.{ field1; field2 } 
> 
> is expanded into
> 
>   { Mod1.Mod2.field1 = field1 ; Mod1.Mod2.field2 = field2 }

I like it, though I can even see an argument for the ~ syntax Eric suggests as 
it dovetails nicely with labels. I especially like your sugar which reduces 
the number of module qualifications. 

Is there any chance we could see a feature like this in the core language 
syntax? Especially since 3.07, I am more inclined to use "private" record 
types a lot more, and since I'd also like to minimize my use of open, this 
lighter syntax makes it even more appealing. 

-- Brian


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

[Caml-list] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

Her is a small file (simplified from GlSurf)
that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2
If you remove the line with thread.yeld it does not SEGV. note:
thread.yeld is not called since Glut.mainLoop is not started, so I am
  puzzled.

Note: all the examples in lablglut distributions appear to work on my 
FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.

So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
the three of them)

Here is the file:

-- test.ml

     ignore(Glut.init Sys.argv);
     Glut.initDisplayMode ~alpha:true ~double_buffer:true ~depth:true () ;
     Glut.initWindowSize ~w:300 ~h:300;
     ignore (Glut.createWindow ~title:"bug demo");
     Glut.idleFunc (Some Thread.yield);
     print_string "titi";
     print_newline ()

--

And the line used to compile it

ocamlc -o testbug functionstubs.o -thread -labels -I +lablglut -I 
+lablGL -I +threads -pp "camlp4o pa_ifdef.cmo -DUNIX" -thread unix.cma 
threads.cma lablglut.cma lablgl.cma -cclib -lGL -cclib -lGLU -cclib 
-lXmu test.ml
bash-2.05b$ ./testbug
Segmentation fault (core dumped)

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

Christophe Raffalli wrote:
> Her is a small file (simplified from GlSurf)
> that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2

FreeBSD 4.8 not 4.3 !!

> If you remove the line with thread.yeld it does not SEGV. note:
> thread.yeld is not called since Glut.mainLoop is not started, so I am
>  puzzled.
> 
> Note: all the examples in lablglut distributions appear to work on my 
> FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.
> 
> So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
> the three of them)
> 
> Here is the file:
> 
> -- test.ml
> 
>     ignore(Glut.init Sys.argv);
>     Glut.initDisplayMode ~alpha:true ~double_buffer:true ~depth:true () ;
>     Glut.initWindowSize ~w:300 ~h:300;
>     ignore (Glut.createWindow ~title:"bug demo");
>     Glut.idleFunc (Some Thread.yield);
>     print_string "titi";
>     print_newline ()
> 
> -- 
> 
> And the line used to compile it
> 
> ocamlc -o testbug functionstubs.o -thread -labels -I +lablglut -I 
> +lablGL -I +threads -pp "camlp4o pa_ifdef.cmo -DUNIX" -thread unix.cma 
> threads.cma lablglut.cma lablgl.cma -cclib -lGL -cclib -lGLU -cclib 
> -lXmu test.ml
> bash-2.05b$ ./testbug
> Segmentation fault (core dumped)
> 

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Gerd Stolpmann]

Am Don, 2003-09-11 um 15.49 schrieb Christophe Raffalli:
> Her is a small file (simplified from GlSurf)
> that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2
> If you remove the line with thread.yeld it does not SEGV. note:
> thread.yeld is not called since Glut.mainLoop is not started, so I am
>   puzzled.
> 
> Note: all the examples in lablglut distributions appear to work on my 
> FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.
> 
> So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
> the three of them)

Maybe another incarnation of this (non-)bug:

http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1820;page=47;user=guest

It seems that FreeBSD's libc_r is not stable enough.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

Complement:

GlSurf 2.0 that uses no thread works on my BSD Box (so it is not a 
problem with the NVidia driver for FreeBSD)

GlSurf 2.1 also crashes with vmthread ... but a bit later and this is 
more difficult to reproduce . (I can send the source if you want, but it 
is not ready for distribution)

I know that NVidia driver are not thread safe, but only yhe main thread 
does openGL call and it works for Linux.

Gerd Stolpmann wrote:
> Am Don, 2003-09-11 um 15.49 schrieb Christophe Raffalli:
> 
>>Her is a small file (simplified from GlSurf)
>>that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2
>>If you remove the line with thread.yeld it does not SEGV. note:
>>thread.yeld is not called since Glut.mainLoop is not started, so I am
>>  puzzled.
>>
>>Note: all the examples in lablglut distributions appear to work on my 
>>FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.
>>
>>So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
>>the three of them)
> 
> 
> Maybe another incarnation of this (non-)bug:
> 
> http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1820;page=47;user=guest
> 
> It seems that FreeBSD's libc_r is not stable enough.
> 
> Gerd

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Gerd Stolpmann]

Am Don, 2003-09-11 um 17.11 schrieb Christophe Raffalli:
> Complement:
> 
> GlSurf 2.0 that uses no thread works on my BSD Box (so it is not a 
> problem with the NVidia driver for FreeBSD)
> 
> GlSurf 2.1 also crashes with vmthread ... but a bit later and this is 
> more difficult to reproduce . (I can send the source if you want, but it 
> is not ready for distribution)
> 
> I know that NVidia driver are not thread safe, but only yhe main thread 
> does openGL call and it works for Linux.

Well, it does not depend on whether you give the -thread or -vmthread 
option, because the executable is always linked against libc_r. I
ran into problems with an application that did not use threads at all.

You can try to disable the link against libc_r by modifying O'Caml's
configure script, and then use -vmthread to select the bytecode
implementation. If the program works then, it is very likely that libc_r
is broken.

> Gerd Stolpmann wrote:
> > Am Don, 2003-09-11 um 15.49 schrieb Christophe Raffalli:
> > 
> >>Her is a small file (simplified from GlSurf)
> >>that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2
> >>If you remove the line with thread.yeld it does not SEGV. note:
> >>thread.yeld is not called since Glut.mainLoop is not started, so I am
> >>  puzzled.
> >>
> >>Note: all the examples in lablglut distributions appear to work on my 
> >>FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.
> >>
> >>So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
> >>the three of them)
> > 
> > 
> > Maybe another incarnation of this (non-)bug:
> > 
> > http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1820;page=47;user=guest
> > 
> > It seems that FreeBSD's libc_r is not stable enough.
> > 
> > Gerd
> 
> -- 
> Christophe Raffalli
> Université de Savoie
> Batiment Le Chablais, bureau 21
> 73376 Le Bourget-du-Lac Cedex
> 
> tél: (33) 4 79 75 81 03
> fax: (33) 4 79 75 87 42
> mail: Christophe.Raffalli@univ-savoie.fr
> www: http://www.lama.univ-savoie.fr/~RAFFALLI
> ---------------------------------------------
> IMPORTANT: this mail is signed using PGP/MIME
> At least Enigmail/Mozilla, mutt or evolution
> can check this signature
> ---------------------------------------------
> 
> -------------------
> 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
> 
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Issac Trotts]

On Thu, Sep 11, 2003 at 03:49:35PM +0200, Christophe Raffalli wrote:
> Her is a small file (simplified from GlSurf)
> that SEGV on FreeBSD 4.3 (with NVidia driver ...) and ocaml-3.07beta2
> If you remove the line with thread.yeld it does not SEGV. note:
> thread.yeld is not called since Glut.mainLoop is not started, so I am
>  puzzled.
> 
> Note: all the examples in lablglut distributions appear to work on my 
> FreeBSD box and the same program (GlSurf) works on Linux, windows and OSX.
> 
> So there is a problem when you use FreeBSD+lablGL/GLUT+thread (you need 
> the three of them)
> 
> Here is the file:
> 
> -- test.ml
> 
>     ignore(Glut.init Sys.argv);
>     Glut.initDisplayMode ~alpha:true ~double_buffer:true ~depth:true () ;
>     Glut.initWindowSize ~w:300 ~h:300;
>     ignore (Glut.createWindow ~title:"bug demo");
>     Glut.idleFunc (Some Thread.yield);
>     print_string "titi";
>     print_newline ()
> 
> --
> 
> And the line used to compile it
> 
> ocamlc -o testbug functionstubs.o -thread -labels -I +lablglut -I 
> +lablGL -I +threads -pp "camlp4o pa_ifdef.cmo -DUNIX" -thread unix.cma 
> threads.cma lablglut.cma lablgl.cma -cclib -lGL -cclib -lGLU -cclib 
> -lXmu test.ml
> bash-2.05b$ ./testbug
> Segmentation fault (core dumped)

Thanks for your bug report.  I don't have a BSD box on hand to reproduce 
the bug, so there isn't much I can do about this at the moment.  Did Gerd
Stolpmann's advice help?

Issac Trotts

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

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


> 
> 
> Thanks for your bug report.  I don't have a BSD box on hand to reproduce 
> the bug, so there isn't much I can do about this at the moment.  Did Gerd
> Stolpmann's advice help?
> 
> Issac Trotts
> 

I will try (tomorrow ?) to check if the problem comes from libc_r ...

But it is probably better to assume a bug in caml_thread_initialize in 
otherlibs/systhreadsin/posix.c for FreeBSD or in other Caml code doing 
openGL initialization.

They are quite a lot of multi-threaded code running well on FreeBSD 
(mozilla, ...) not to assume first a bug in libc_r when a five line bit 
of Caml code that essentially initializes openGL and call 
caml_thread_initialize does SEGV.

But may be they are other reason to suspect libc_r ?

I will try both to compile my small bit of code without libc_r and maybe 
try to localize the line in caml_thread_initialize that trigger the 
crash (I surely can do that because no call to caml_thread_initialize => 
no crash).

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

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


By the way, I think vmthread are no use for a program like Glsurf:

They are two threads and once the openGL thread has called Glut.mainLoop 
it will only call Caml code from callback from C ... and is seems that 
this prevent the premption of the thread and the computing thread will 
never have a chance to run, even if I call Thread.yield in the Idle 
callback function (at least this is what I observed)

Am I right ?

This limits a lot the use of vmthread : no native code compilation, 
requirement for all threads to run "toplevel" Caml code (no Caml code 
from C) often and may be other limitation that I don't know of. That's a 
lot :-(

And just a remark, like other people, I feel my machine is much faster 
(not for pure computation) under FreeBSD than Linux (mdk 9.0). Starting 
KDE or compiling ocaml (especially the ./configure script), seemed much 
faster. I should do some timing.

  --
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] FreeBSD + lablglut + thread: bug or not bug

[Issac Trotts]

On Thu, Sep 11, 2003 at 10:09:14PM +0200, Christophe Raffalli wrote:
> 
> By the way, I think vmthread are no use for a program like Glsurf:
> 
> They are two threads and once the openGL thread has called Glut.mainLoop 
> it will only call Caml code from callback from C ... and is seems that 
> this prevent the premption of the thread and the computing thread will 
> never have a chance to run, even if I call Thread.yield in the Idle 
> callback function (at least this is what I observed)
> 
> Am I right ?

You are right that Glut.mainLoop makes vmthreads useless, but this doesn't
imply that vmthreads are of no use for Glsurf (see below).

> This limits a lot the use of vmthread : no native code compilation, 
> requirement for all threads to run "toplevel" Caml code (no Caml code 
> from C) often and may be other limitation that I don't know of. That's a 
> lot :-(

Another way to look at it is that it limits the use of GLUT, which ought
to have an open event loop as in SDL and OCaml's Graphics library.  Using 
OCamlSDL would probably make it possible to use vmthreads, though I
haven't tried it myself.

> And just a remark, like other people, I feel my machine is much faster 
> (not for pure computation) under FreeBSD than Linux (mdk 9.0). Starting 
> KDE or compiling ocaml (especially the ./configure script), seemed much 
> faster. I should do some timing.

Have you tried recompiling your Linux kernel?  Which distribution are you
running?

Issac Trotts


-- 

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

I was wrong to say other multi-threaded code work: here is a stack of
a crashed kcontrol ...

.....
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...0x28ec256c in __sys_poll ()
    from /usr/lib/libc_r.so.4
#0  0x28ec256c in __sys_poll () from /usr/lib/libc_r.so.4
#1  0x28ec1ab8 in _thread_kern_sched_state_unlock () from 
/usr/lib/libc_r.so.4
#2  0x28ec147d in _thread_kern_scheduler () from /usr/lib/libc_r.so.4
#3  0x0 in ?? ()

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Gerd Stolpmann]

Am Fre, 2003-09-12 um 07.57 schrieb Christophe Raffalli:
> I was wrong to say other multi-threaded code work: here is a stack of
> a crashed kcontrol ...

I would not conclude that from this stack trace. libc_r is a user-level
multi-threading emulation, and many system calls (such as "poll" here)
are redefined to get the effect of the emulation. Maybe the code crashes
in __sys_poll because kcontrol called "poll" with an invalid pointer; a
userland threading library cannot check whether addresses are valid like
the kernel does for real system calls.

Concerning the stability of libc_r I found the bug that the signal mask
is not restored after the signal routine has finished execution. For
most multi-threaded applications this is not a big problem: They usually
do not define signal handlers at all, because this has the disadavantage
that it is undefined in which thread the signal handler runs. Instead,
there is often a separate thread that watches for signals (sigsuspend).
However, O'Caml relies on correct signal semantics, especially for
multi-threaded applications, because it uses an alarm timer to implement
its own time-sharing policy. Consider O'Caml as a "stress test" for the
multi-threading implementation.

Gerd

> 
> .....
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...0x28ec256c in __sys_poll ()
>     from /usr/lib/libc_r.so.4
> #0  0x28ec256c in __sys_poll () from /usr/lib/libc_r.so.4
> #1  0x28ec1ab8 in _thread_kern_sched_state_unlock () from 
> /usr/lib/libc_r.so.4
> #2  0x28ec147d in _thread_kern_scheduler () from /usr/lib/libc_r.so.4
> #3  0x0 in ?? ()
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
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] FreeBSD + lablglut + thread: bug or not bug

[Christophe Raffalli]

My but with labgGL on FreeBSD was not with Caml nor libc_r but with the
  FreeBSD NVidia driver.

Everything is better with Utah-GLX (at the moment, they say that only 
NVidia card works, but that's what I have)!

So no bug to track on Caml.

By the way do not even try the NVidia FreeBSD driver, I had system 
crashes and I even lost some files and since I stopped using it no more 
crashes.

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

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