sponge45 changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
nonpop has quit ["Leaving."]
nonpop has joined #ocaml
smimou has quit ["bli"]
nonpop has left #ocaml []
nonpop has joined #ocaml
mbishop has quit [Remote closed the connection]
nonpop has left #ocaml []
velco has quit ["I'm outta here ..."]
jdev has quit [Read error: 104 (Connection reset by peer)]
swater has quit ["Quat"]
buluca has quit [Remote closed the connection]
malc_ has joined #ocaml
malc_ has quit ["leaving"]
mbishop has joined #ocaml
triple__ has joined #ocaml
danly has quit ["Leaving"]
bluestorm has joined #ocaml
danly has joined #ocaml
jdev has joined #ocaml
bluestorm has quit [Remote closed the connection]
danly has quit [Read error: 104 (Connection reset by peer)]
pauld has quit [Read error: 110 (Connection timed out)]
bluestorm has joined #ocaml
shawn_ has joined #ocaml
_velco has joined #ocaml
_JusSx_ has joined #ocaml
buluca has joined #ocaml
smimou has joined #ocaml
swater has joined #ocaml
llama32 has joined #ocaml
shawn_ has quit [Read error: 104 (Connection reset by peer)]
<llama32> does ocaml use native threading?
<smimou> it can, yes
<llama32> hmm
<llama32> i read somewhere that it's garbage collector isn't concurrent, so it won't thread across multiple processors... it's still possible to pause the other threads and/or constrain them to one CPU with native threading- but it doesn't make a lot of sense [constraining them to one CPU anyway]... was i mistaken about the gc [old documentation perhaps]?
<smimou> no you're right
<smimou> there is at most one caml thread running at a given time
<smimou> (there's a big global mutex)
<llama32> ah ok
<llama32> then what's the point of native threading?
<smimou> using the native implementation of thread contexts, etc.
<smimou> and anyway if you only have one processor, it's not very different from the usual threading
<llama32> thread contexts?
<llama32> does ocaml unlock the mutex when entering C code?
<llama32> like, should i be worried about calling blocking C code?
<smimou> if the C code is in a "blocking section" then you shouldn't be worried
<smimou> begin_blocking_section / end_blocking_section instructuctions mean that you release the global mutex
<llama32> ah ok
nonpop has joined #ocaml
_velco is now known as velco
piggybox has quit [Read error: 110 (Connection timed out)]
piggybox has joined #ocaml
Smerdyakov has quit [Remote closed the connection]
zak_ has joined #ocaml
llama32 has quit [Read error: 110 (Connection timed out)]
Shimei has quit [Connection timed out]
Shimei has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
zak_ has quit [Read error: 110 (Connection timed out)]
bluestorm has quit ["Konversation terminated!"]
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
bluestorm has joined #ocaml
<trurl> p
Eriridius has joined #ocaml
Eriridius has quit [Remote closed the connection]
Eriridius has joined #ocaml
Eriridius is now known as Eridius|lappy
Eridius|lappy has quit []
Smerdyakov has joined #ocaml
<dark_light> <smimou> there is at most one caml thread running at a given time > isn't this a big limitation?
dylan has joined #ocaml
dylan has left #ocaml []
slipstream has quit [Read error: 110 (Connection timed out)]
pango has quit ["Leaving"]
<smimou> dark_light: why ?
<dark_light> eell, how can i will parallize? (with OS's threads?)
<Smerdyakov> Threading itself is not wedded to the idea of parallelization.
<Smerdyakov> Threads provide a very useful abstraction mechanism, just like functions.
<dark_light> Smerdyakov, but it may help
<Smerdyakov> And they also work well with minimizing effects of hardware delays by juggling around different tasks.
pango has joined #ocaml
<Smerdyakov> dark_light, yes, it would be nice to have multi-processing. But keep in mind that that is a _separate_ feature from "threading," that it takes much additional work, and that one-at-a-time threads are already very useful.
<dark_light> currently it's impossible to have multi-processing eith ocaml? even with posix threads?
<Smerdyakov> You can, of course, use separate OCaml processes.
<Smerdyakov> I think that's the only way.
<dark_light> hmmmm.
slipstream has joined #ocaml
slipstream-- has joined #ocaml
slipstream has quit [Read error: 110 (Connection timed out)]
_JusSx_ has left #ocaml []
<mbishop> haskell has experimental SMP support, and is getting more (thanks to funding from Microsoft Research)
gentoo has joined #ocaml
gentoo has quit ["changing servers"]
nonpop has left #ocaml []
nonpop has joined #ocaml
nonpop has quit ["Leaving."]
nonpop has joined #ocaml
nonpop has quit ["Leaving."]
nonpop has joined #ocaml
slipstream has joined #ocaml
_JusSx_ has joined #ocaml
bluestorm is now known as bluestorm_aw
mbishop has quit [Remote closed the connection]
_JusSx_ has left #ocaml []
_JusSx_ has joined #ocaml
slipstream-- has quit [Read error: 110 (Connection timed out)]
klapmuetz has joined #ocaml
mbishop has joined #ocaml
shawn_ has joined #ocaml
shawn_ has quit [Read error: 54 (Connection reset by peer)]
<buluca> (18:44:01) dark_light: currently it's impossible to have multi-processing eith ocaml? even with posix threads?
<dark_light> hmn.
<buluca> dark_light: what about ocamlp3l?
<dark_light> i don't know, what is it?
<buluca> but there's a tutorial shipping with the sourcecode
<dark_light> hmm
sponge45 has joined #ocaml
klapmuet1 has joined #ocaml
klapmuetz has quit [Read error: 60 (Operation timed out)]
johnnowak has joined #ocaml
bluestorm_aw has quit ["Konversation terminated!"]
velco has quit ["I'm outta here ..."]
malc_ has joined #ocaml
lmbdwr has joined #ocaml