Browse thread
effect of -thread with ocamlc/ocamlopt -c
-
Trevor Jim
- Jonathan Roewen
-
Jonathan Roewen
-
Trevor Jim
- Jacques Garrigue
-
Trevor Jim
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-09-13 (16:32) |
From: | Jacques Garrigue <garrigue@m...> |
Subject: | Re: [Caml-list] effect of -thread with ocamlc/ocamlopt -c |
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