Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-03-02 (18:29)
From: Christophe Raffalli <Christophe.Raffalli@u...>
Subject: Re: GC + thread
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

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

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