OCamlMakefile

OCamlMakefile

[Remi VANICAT]

Français :

Bonjour,

j'ai ramener chez moi le Makefile_caml.tpl disponible a l'INRIA, et je
me suis aperçut d'un problème : Il n'y a pas de licence seulement un
"Distributed only by permission". Dans quel mesure j'ai le droit de le
modifier et de le redistribuer? merci d'avance.

English :
I have found the Makefile_caml.tpl on the INRIA server, but there is no
license for it, which one apply?

Thanks
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat

Re: OCamlMakefile

[Pierre Weis]

> Français :
> 
> Bonjour,
> 
> j'ai ramener chez moi le Makefile_caml.tpl disponible a l'INRIA, et je
> me suis aperçut d'un problème : Il n'y a pas de licence seulement un
> "Distributed only by permission". Dans quel mesure j'ai le droit de le
> modifier et de le redistribuer? merci d'avance.

C'est la licence INRIA: totalement libre à condition de laisser la
notice. Vous avez même le droit de vendre ce fichier à qui voudra vous
l'acheter.

> English :
> I have found the Makefile_caml.tpl on the INRIA server, but there is no
> license for it, which one apply?

The INRIA licence: you're free to do what you want with this file as
soon as the copyright notice is not removed. You can even sell the
file if you can...

-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis

GC + thread

[Christophe Raffalli]

The following extension for Ocaml GC seems to me simple and necessary (I
really do need it):

It considers only channels dans thread and I will describe it for a mark
and swip GC.

rule 1: a channel can be marked by the GC in two ways: read or write.
rule 2: a channel that is accssible by the GC in the usual way is both
marked read and write
        (usual means in a way no covered by rule 3).
rule 3: if a closure if blocked while trying to read from channel R_1,
..., R_n
                                         or to write from channel W_1,
..., W_n
        - the channels R_1,..,R_n are marked as read
        - the channels W_1,..,W_n are marked as write
        - the closure will be examined by the GC if and only if 
          one the channel R_i is marked write or one the channel W_i is
marked read
          if the condition is not immidiately true, the examination of
the closure is 
          postponed.
        - if no channel R_i are marked write and no channel W_i are
marked 
           read at the end of the mark pass, the closure and the
corresponding thread
          can be safely destroyed (the thread will never wake up).\x13


So clearly this require only a modification of the GC of blocked thread
and needs to keep to extra bits for channels (this is not a big cost).

I would be good to also introduce mono-directional channel (the function
create return a pair with an in_channel and an out_channel). In this
case the GC ca be optimized to collect more threads in a trivial way
(when the GC reaches the in part of a channel it is only marked read and
if the GC reaches the out part of a channel it is only marked write).

This extension is also necessary (it is easy to have realistic examples
where the GC would collect much more thread with this extension).

What do you think of that ?
-- 
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

Re: GC + thread

[Max Skaller]

Christophe Raffalli wrote:
> This extension is also necessary (it is easy to have realistic examples
> where the GC would collect much more thread with this extension).
> 
> What do you think of that ?

Why is this necessary? In particular, because in/out channels have
reduced functionality, I have opted to use Unix.file_descr instead:
these are converted to/from in/out channels if necessary.

It seems to me this particular problem is part of a more general
one concerning resource acquisition and threads?

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: GC + thread

[Christophe Raffalli]

Max Skaller wrote:
> 
> Christophe Raffalli wrote:
> > This extension is also necessary (it is easy to have realistic examples
> > where the GC would collect much more thread with this extension).
> >
> > What do you think of that ?
> 
> Why is this necessary? In particular, because in/out channels have
> reduced functionality, I have opted to use Unix.file_descr instead:
> these are converted to/from in/out channels if necessary.

in/out channels are not necessary. As you create the pair, there is no
extra functionnality.
The point is just to help a GC extended to collect potentialy dead
thread: 

If a thread T is blocked while trying to read from channel A and there
is an active thread with a pointer on A, you can not collect the thread
T.

If a thread T is blocked while trying to read from channel A and there
is only active thread with a pointer on the in part of A, you can
collect the thread T : no thread will ever be able to write on channel A
and T will never wakeup. 

This situation arises in practice every time you have thread which will
only write (or read) on a given channel. Then it is better to let the GC
know this.

As the actual version of Ocaml can not collect threads, it is clear that
in/out channel are useless ...

But there are a lot of thread applications (like a virtual machine for
any process calculus like the pi-calculus) which really needs a GC
collecting thread in the way I described in my previous mail.



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

Re: GC + thread

[Christophe Raffalli]

John Max Skaller wrote:
> 
>         Perhaps I didn't explain myself well. I understand there
> is a problem with in_channel and out_channel. This same problem
> can arise with Unix.descr files (although there is a rich enough
> facility
> to avoid this problem by always doing non-blocking operations?)
> 

It is not really a "problem". It is just that they can help a GC
collects blocked thread (see below).

>         I guess the same happens with Event.channels?
> 

All what I said is only for Event.channels and no other types of
channels.
Perhaps I didn't explain myself well too !

>         My question is really: isn't the scenario you describe
> more general? Is there some way that your solution can be applied
> to a wider class of resources than in/out channels?

The point is to try to make the GC collect blocked threads. And the
algorithm I described is needed and you do not need really more (or more
exactly you can not hope for more because a GC can not be perfect)

Let us examine how a thread can be blocked forever:

- blocked on a channel (in/out or both): this can be solved by the
extended GC.

- blocked on a file: you can do nothing: the GC can not scan the outside
world!

- blocked on a mutex: If the thread never wakeup it means that someone
forgotten to release a ressource. This is probably a bug of the program,
it is not really necessary for the GC to care.

- blocked on a condition: Same reasonning than for mutex.

- blocked waiting for another thread: this is also probably a bug.
but in this case it is probably OK for the GC to collect all thread
waiting for a thread which can be itself collected.

To extend the GC with the three last cases you can see that they are
easely codable using in/out channels and get the proper behavior. Notice
that coding with general channel (not in/out) would not lead to the
proper behavior of the GC !

Let us do it for the join operation (waiting for another thread):

You use an out channel for each thread where you send (broadcast)
something as soon as you terminate.

You use the in part of the out channel of a thread to wait for it.

If a thread A is blocked waiting on another thread B which is "dead" for
the GC. Then the GC will not scan the out channel and will detect that
the first thread is dead two (no accessible pointer on the out channel).

If another thread has a pointer on the in part of the out channel there
is no problem. But if we did not make the in/out distinction, then the
GC could not collect anymore the blocked threadv A.

Conclusion: every thread should be considered by the GC as an out
channel which is visible by the GC if the thread is alive. Waiting for a
thread is considered as waiting on the in part of the channel.

I think the mecanism I described is standard in language like pict,
isn't it ? And it shoud (must) be in any language with threads and GC.


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