caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: trevor@research.att.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] effect of -thread with ocamlc/ocamlopt -c
Date: Thu, 14 Sep 2006 01:34:33 +0900 (JST)	[thread overview]
Message-ID: <20060914.013432.41630933.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <45081CC0.8010004@research.att.com>

The question is a bit different depending on whether you use system
threads or vmthreads. Note that if your platform supports system
threads, they are the ones used with the -thread option, while on
platforms without them -thread and -vmthread are equivalent.

For system threads, the standard library is unchanged, and you don't
need the -thread option for modules that don't use threads. So there
is no problem.

For vm threads, some modules from the standard library have different
implementations (namely, Pervasives, Marshal and Unix). So it is
essential that you use the -thread option to link with them. Note
however that the interfaces being identical, again you don't need
-thread for unrelated modules, so that in practice you shouldn't see
any difference with system threads. IIRC, at some point in the past
some modified functions were defined as external in the standard
library, making interfaces different, so that using -thread everywhere
was a strict requirement.

Jacques Garrigue

From: Trevor Jim <trevor@research.att.com>
> Well, I'm still confused.  Consider that a bunch of the standard
> libraries use Pervasives, but I can see that the standard library
> is not compiled with -thread.  So clearly we are meant to use the
> standard library compiled without -thread, with threads.cm[x]a.
> 
> So, I still don't understand when I can combine code compiled
> without -thread with code compiled with -thread.
> 
> -Trevor
> 
> Jonathan Roewen wrote:
> > Oh wait, I'm sorry. Yes, there is good reason: it uses a different
> > version of Pervasives internals.
> > 
> > Depending on when linking is done for each part, you may end up with
> > conflicting implementations of Pervasives in your final program: so
> > [IO] operations that can block will block whole program instead of
> > running thread blocking, and another thread running instead.
> > 
> > So maybe if it uses no IO, and no threading functions, it might be
> > okay -- there are no guarantees when you do these sorts of things (:
> > 
> > Jonathan


  reply	other threads:[~2006-09-13 16:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-12 17:07 Trevor Jim
2006-09-12 21:29 ` [Caml-list] " Jonathan Roewen
2006-09-12 21:34 ` Jonathan Roewen
2006-09-13 14:59   ` Trevor Jim
2006-09-13 16:34     ` Jacques Garrigue [this message]
2006-09-13 16:57       ` Trevor Jim
2006-09-13 17:40       ` Xavier Leroy

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=20060914.013432.41630933.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@yquem.inria.fr \
    --cc=trevor@research.att.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).