Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
To: Max Skaller <maxs@in.ot.com.au>
Cc: caml-list@inria.fr
Subject: Re: GC + thread
Date: Thu, 02 Mar 2000 10:31:35 +0100	[thread overview]
Message-ID: <38BE34F7.1B4405E8@univ-savoie.fr> (raw)
In-Reply-To: <38BDD0C9.D26E970@in.ot.com.au>

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



  reply	other threads:[~2000-03-02 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-28 12:06 OCamlMakefile Remi VANICAT
2000-02-28 23:15 ` OCamlMakefile Pierre Weis
2000-02-29 15:49 ` GC + thread Christophe Raffalli
2000-03-02  2:24   ` Max Skaller
2000-03-02  9:31     ` Christophe Raffalli [this message]
     [not found]       ` <38BFEBFB.50487A27@maxtal.com.au>
2000-03-03 18:16         ` Christophe Raffalli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38BE34F7.1B4405E8@univ-savoie.fr \
    --to=christophe.raffalli@univ-savoie.fr \
    --cc=caml-list@inria.fr \
    --cc=maxs@in.ot.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox