caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: David McClain <dmcclain@azstarnet.com>, caml-list@inria.fr
Subject: Re: Threads Library
Date: Thu, 13 Jan 2000 10:32:40 +0100	[thread overview]
Message-ID: <20000113103240.36062@pauillac.inria.fr> (raw)
In-Reply-To: <000c01bf51e0$ef8295a0$250148bf@vega>; from David McClain on Wed, Dec 29, 1999 at 02:41:49AM -0700

> However, unlike CML, (on Windows/NT at least) the GC does not discard
> threads hung up on channels that are no longer in use by active threads.
> Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
> experiments generated thousands of threads before I had to kill off the
> program).

This is correct.  Currently, there is no automatic reclaimation of
threads whose identifier (the associated Thread.t value) is
unreachable, because those threads could be "daemon" threads that do
useful work in the background.

> Secondly, it would appear that the semantics of "with_abort" require that
> the wrapper function be called ahead of all "with" functions. But
> experiments where a with-function raises an exception bypass the actions of
> pending "with_abort" functions on non-selected channels. So evidently, one
> should not permit the use of uncaught exceptions inside of "with" functions.
> 
> Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
> about the use of indefinite recursion triggered by a with-function. It would
> seem that one should treat composite event lists in much the same manner as
> "try-with" when it comes to recursion inside a try (resp. with) clause.
> Instead of tail calling from the "with" clause one should return a value to
> the outer level of the "sync" or "select", and then "match" on that value
> before recursing.

I haven't read Reppy's book yet, so I'm not absolutely sure I follow
you here, but generally speaking it is true that the "with_abort"
mechanism is more heavyweight in OCaml than in CML, because it is
implemented with "real" threads in OCaml while CML uses a much more
lightweight callcc-based implementation.

- Xavier Leroy




  reply	other threads:[~2000-01-13 16:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-29  9:41 David McClain
2000-01-13  9:32 ` Xavier Leroy [this message]
2000-01-15  2:14   ` Dynamic loading and building of shared libraries skaller
2000-01-17  3:59     ` Ian Zimmerman
2000-01-17  8:00     ` STARYNKEVITCH Basile
2000-01-13 19:49 Threads Library Juergen Pfitzenmaier
2004-11-22 21:20 Threads library Ernesto Posse

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=20000113103240.36062@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=dmcclain@azstarnet.com \
    /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;
as well as URLs for NNTP newsgroup(s).