<kerneis>
similarly, for unix: echo '<test.ml>: use_unix' >> _tags
<BitPuffin>
yeah
<BitPuffin>
still got that error though :s
<kerneis>
a good way to find the relevant tags is to do: ocamlbuild -documentation | grep unix (for instance)
<BitPuffin>
nice
eikke__ has quit [Ping timeout: 240 seconds]
<kerneis>
http://paste.debian.net/ show us the output of: cat _tags; ocamlbuild -classic-display -pkgs lwt,core_kernel,batteries,cohttp,cohttp.lwt test.native
<kerneis>
this makes absolutely no sense to me. My only guess would be that one of the libraries you are linking to is already bundling unix - but it's weird. try building test.byte, the error message for double-linking is sometimes more informative
_andre has joined #ocaml
maattdd has joined #ocaml
NoNNaN has joined #ocaml
ollehar1 has joined #ocaml
dsheets has joined #ocaml
fraggle_ has quit [Read error: Connection reset by peer]
maattdd has quit [Ping timeout: 244 seconds]
rand000 has joined #ocaml
fraggle_ has joined #ocaml
<sagotch>
whitequark , jpdeplaix is llvm (3.5) binding using MCJIT when calling Llvm_executionengine.ExecutionEngine.create?
<sagotch>
if no, is there a way to do it? (llvm has llvm::EngineBuilder::setUseMCJIT (bool Value), but binding seems to miss it).
<jpdeplaix>
sagotch: I don't know. I don't use this module
<sagotch>
is llvm (3.5) binding using MCJIT when calling Llvm_executionengine.ExecutionEngine.create?
q66_ is now known as q66
lordkryss has quit [Ping timeout: 252 seconds]
SethTisue has joined #ocaml
mcclurmc has joined #ocaml
<whitequark>
sagotch: MCJIT is not supported in the binding
<sagotch>
not yet, or is it just not planned at all?
<sagotch>
Because from the llvm irc channel: "Make sure you're using MCJIT though, or you'll have more pain in the near future." "(We're removing non-MC-JIT as soon as we can)"
<BitPuffin>
for some reason it's not executing the threads. The only missing code here is the code that calls do_it_ten_times_threaded with all the args
<kerneis>
BitPuffin: is it on purpose that you mix Lwt and OCaml threads?
<BitPuffin>
kerneis: yes
<BitPuffin>
So the code I will write will have one thread (not ten), that runs lwt. However the thread will complete if it's got nothing more to do (wasteful to have an event loop running all the time) and when a new library call happens it starts a new thread etc
<BitPuffin>
so yeah
<BitPuffin>
I need to mix both to test this :)
ygrek_ has joined #ocaml
<BitPuffin>
is there a way to make the main thread sleep for like 20 seconds or something?
<BitPuffin>
ah delay
lordkryss has quit [Ping timeout: 255 seconds]
<adrien_oww>
or Unix.sleep
darkf has quit [Quit: Leaving]
<BitPuffin>
doesn't seem like anything is happening
<adrien_oww>
if it's sleeping, it's quite expected :D
<BitPuffin>
well no I mean in the other threads
<BitPuffin>
and it's still delayed, even though I said 20 seconds, weird
<BitPuffin>
Thread.delay 1.0;
<BitPuffin>
printf "I was delayed!"
<BitPuffin>
never reaches printf
<def`>
printf "I was delayed!%!" ?
<adrien_oww>
\n too because you're well-mannered
<BitPuffin>
oh snap
<def`>
:)
<BitPuffin>
always
<BitPuffin>
still though it should stop executing :P
<BitPuffin>
yeah, it still doesn't get past the delay
<BitPuffin>
that's really strange
<BitPuffin>
is it forbidden to use it on main thread?
<adrien_oww>
dunno
<adrien_oww>
I always use Unix.sleep
<def`>
dunno, I don't think so, that would be strange.
<def`>
vmthreads or system threads ?
<BitPuffin>
system
<BitPuffin>
I think
<BitPuffin>
and hope
<def`>
Yeah, likely system threads. I don't know what happens :p
<Anarchos>
BitPuffin i always use fflush after printf.
<adrien_oww>
%! does the same
<Anarchos>
adrien_oww didn't know this one, thanks for the information
<BitPuffin>
Anarchos: the program should reach its end though after the sleep
<adrien_oww>
oh you're mixing system threads and lwt
<BitPuffin>
adrien_oww: yeah I am
<adrien_oww>
Anarchos: format would be "foo: %d\n%!"; extremely handy
<BitPuffin>
adrien_oww: the library I'm writing has to mix system threads and lwt :P
bjorkintosh has joined #ocaml
<BitPuffin>
however it will only use one system thread
<BitPuffin>
I'll have some sort of "has thread" variable or something :P
<adrien_oww>
bah, I'm mostly unable to do anything today it seems (including reading code)
<adrien_oww>
BitPuffin: but why system locks when dealing with lwt code?
<BitPuffin>
adrien_oww: because the lock is supposed to be locking between the system threads
<BitPuffin>
so that not two system threads write the file at the same time
<BitPuffin>
or read while someone is writing
<BitPuffin>
:P
<adrien_oww>
yeah I think it cannot work
<adrien_oww>
you have a blocking operation inside something running in lwt
<BitPuffin>
yeah?
<adrien_oww>
BitPuffin: can't you "swap" lines 44 and 45?
<adrien_oww>
i.e. do the blocking call outside the lwt loop
<BitPuffin>
isn't writing blocking as well though?
<BitPuffin>
also I don't see why it wouldn't work just because a call is blocking
<adrien_oww>
it is but it's "OK" in many cases
<def`>
it's strange to mix lwt and threads :'
<adrien_oww>
thing is that the mutex locking might never return
<BitPuffin>
def`: well how else would you write a library that uses lwt behind the scenes to the un-knowing person calling via a C api
<adrien_oww>
I'd swap lines 44 and 45 :P
<def`>
BitPuffin: I would let lwt handle exculsive access
<adrien_oww>
def`: the point is that your C program calls the OCaml library which runs the lwt loop
<adrien_oww>
that function call will block
<BitPuffin>
adrien_oww: but 44 is a ), and 45 is empty
<def`>
I think you got line numbers wrong adrien_oww ;)
<adrien_oww>
so you need some kinf of threading on which both C and OCaml agree
<adrien_oww>
BitPuffin: I had:
<adrien_oww>
>|= fun _ -> printf "%i: %s" num (read_whoami file)
<adrien_oww>
)
<BitPuffin>
well that wouldn't work
<BitPuffin>
you can't read from the file before the previous operation is done
cago has quit [Remote host closed the connection]
<BitPuffin>
ie if you can't wait for it to do the web request and write the result to disk before reading it what's the point of reading it?
<adrien_oww>
can you write down the task you need to do in the OCaml library?
<BitPuffin>
in this proof of concept thing or the actual library?
<adrien_oww>
hmm?
<BitPuffin>
yeah you mean this test code or the "real" code I will be writing if this works?
ollehar1 has quit [Ping timeout: 248 seconds]
sagotch has quit [Remote host closed the connection]
<BitPuffin>
what the real library will do is that it will have an internal operation queue that exists in the main process or whatever. Then the code that actually grabs operations off the queue runs in its own thread that has its own async thingy. And this code will lock the operation queue when taking an operation off it, then unlock, and continue executing the operation. And if there is no more operations in the queue
<BitPuffin>
the thread will reach its end and terminate. And then when you add something new to the queue and there is no thread running it starts it again
<BitPuffin>
the actual tasks in the operation queue is things like file downloads and local sqlite database updates based on the results of file downloads and stuff
<BitPuffin>
then there will be some extra complexity with for example database queries. The main thread can do queries without going through the queue, and it will lock the db, so if the operation queue is updating the db it needs to lock and stuff like that
<BitPuffin>
but yeah in the real lib there will only ever be one lwt event loop running
<BitPuffin>
and it will not always be running
<BitPuffin>
does it make sense adrien_oww?
<adrien_oww>
I think but I need to re-read
<adrien_oww>
(brain is shut off due to overheating)
<BitPuffin>
:)
<adrien_oww>
mrvn: libocaml-uucp which means "ocaml library to do uucp"
<adrien_oww>
mrvn: which, I completely agree, is a completely crap nam
<adrien_oww>
e
slash^ has joined #ocaml
<adrien_oww>
BitPuffin: I'd start a system thread that waits on data and then runs a fresh Lwt_main.run
yacks has joined #ocaml
<BitPuffin>
adrien_oww: well that's pretty similar
<BitPuffin>
adrien_oww: but it doesn't seem like Threads work at all
<adrien_oww>
except the locking would be outside of Lwt_main.run
<BitPuffin>
I don't understand why it doesn't work to lock in Lwt though
<adrien_oww>
was it from another _system_ thread you were unlocking? and maybe lwt has some state (that, I can't say for sure)
<BitPuffin>
adrien_oww: in this code locking and unlocking happens in the same system thread
<adrien_oww>
that won't wokr
<adrien_oww>
work*
<BitPuffin>
why not? It makes perfect sense that the thread that locks should unlock
<adrien_oww>
ah
<adrien_oww>
yeah, right
<adrien_oww>
but a given thread doesn't do two locks or two unlocks on the same mutex, right?
<BitPuffin>
that would deadlock or crash
<BitPuffin>
as far as I can tell it only locks, unlocks the read and write mutex. And then locks and unlocks the read mutex
jludlam has quit [Ping timeout: 255 seconds]
shinnya has quit [Ping timeout: 244 seconds]
keen_ has left #ocaml ["Killed buffer"]
WraithM has joined #ocaml
eikke__ has quit [Remote host closed the connection]
jludlam has joined #ocaml
Hannibal_Smith has joined #ocaml
Eyyub has joined #ocaml
maxibolt is now known as thizanne
tnguyen1 has joined #ocaml
tnguyen1 has quit [Client Quit]
mcclurmc has quit [Remote host closed the connection]
demonimin has quit [Read error: Connection reset by peer]
mcclurmc has joined #ocaml
lordkryss has joined #ocaml
philtor_ has joined #ocaml
ollehar has quit [Read error: Connection reset by peer]
kakadu_ has quit [Ping timeout: 246 seconds]
demonimin has joined #ocaml
eikke__ has joined #ocaml
mcclurmc has quit [Remote host closed the connection]
TaXules has joined #ocaml
mcclurmc has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
Hannibal_Smith has joined #ocaml
divyanshu has quit [Ping timeout: 264 seconds]
oriba has joined #ocaml
divyanshu has joined #ocaml
ollehar has joined #ocaml
tane has joined #ocaml
ollehar has quit [Ping timeout: 260 seconds]
racycle has joined #ocaml
octachron has quit [Quit: Page closed]
yomimono has joined #ocaml
<whitequark>
BitPuffin: I don't think you're doing it right
ollehar has joined #ocaml
<whitequark>
the proper way would be to offload calls to sqlite, or whatever else is blocking on a system call, to the thread pool that lwt keeps for this exactpurpose
bjorkintosh has quit [Ping timeout: 260 seconds]
eikke__ has quit [Ping timeout: 240 seconds]
Kakadu has joined #ocaml
<BitPuffin>
whitequark: well yeah the lib wouldn't necessarily have a db lock, sqlite might already have that built in
<BitPuffin>
it was an example of some extra possible complexity that might arise
<whitequark>
I mean, you don't need to fiddle with mutexes or threads explicitly
<whitequark>
Lwt_unix has an API
<BitPuffin>
I know about Lwt_preemptive
<BitPuffin>
but it assumes that you are the main thread
<Drup>
look at Lwt_pool
<BitPuffin>
I am not the main thread
<whitequark>
why are you not the main thread?
<BitPuffin>
and it doesn't matter if Thread doesn't work at all does it?
<BitPuffin>
whitequark: because I am a library
<whitequark>
BitPuffin: do you export an Lwt API?
<BitPuffin>
who needs my own internal thread
<whitequark>
or a "blocking" one?
<BitPuffin>
whitequark: I expose a C API that is abstracted
<whitequark>
oh
<whitequark>
nevermind then
<BitPuffin>
so yeah
<BitPuffin>
not sure what to do
<BitPuffin>
might have to go C or somethiing
<BitPuffin>
but that wouldn't be nice
<BitPuffin>
pascal seems to be an option, but that's not very nice either
<whitequark>
pascal?
<seliopou>
anybody here familiar with the internals of async_unix, specifically writer0.ml? I'm curious why `flushed w` returns `Deferred.never ()` when the writer is closed rather than throwing an exception.
<BitPuffin>
whitequark: it's a programming language
<whitequark>
BitPuffin: ... I know.
<whitequark>
how exactly would it be different from C here
<BitPuffin>
it's not very different from C
<BitPuffin>
although it's a bit more safe it semes
bjorkintosh has joined #ocaml
jwatzman|work has joined #ocaml
jwatzman|work has quit [Changing host]
jwatzman|work has joined #ocaml
clog_ has quit [Quit: ^C]
clog has joined #ocaml
<ggole>
...wow, been years since I've hacked pascal
<BitPuffin>
:P
<BitPuffin>
still don't know
<BitPuffin>
bleh
<whitequark>
use rust or something
<whitequark>
using pascal for new projects is as malicious to your users as using c
<BitPuffin>
rust doesn't work on ios yet
<BitPuffin>
because of an llvm bug
<whitequark>
that'll be fixed soon...
<BitPuffin>
yeah
<BitPuffin>
but I have a deadline
<BitPuffin>
:(
<whitequark>
cherry-pick the llvm patch?
<BitPuffin>
who knows when the patch comes though
<BitPuffin>
it's a bit scary
<ggole>
Cmon, it's no fun if you aren't bleeding all over the place
<BitPuffin>
:P
<ggole>
(If this is a commercial project, making a conservative choice is more or less sensible.)
<NoNNaN>
your choice must include fortran or apl
<BitPuffin>
it is
<whitequark>
ggole: people using mongodb seem to disagree
<ggole>
Well, they should stop that.
<BitPuffin>
agreed
<BitPuffin>
although we do use mongodb
<BitPuffin>
So I just silently judge
jludlam has quit [Ping timeout: 248 seconds]
<whitequark>
BitPuffin: then you'll be fine using the LLVM patch...
<ggole>
Because any breakage will be overshadowed?
* ggole
snarks it up on the internets
hhugo has quit [Quit: Leaving.]
<whitequark>
ggole: exactly
BitPuffin has quit [Read error: Connection reset by peer]
<ggole>
Goddammit, brain, why don't you tell me about the proper way to write this code *before* I type it all out? -_-
BitPuffin has joined #ocaml
<BitPuffin>
whitequark: it has already been patched?
<whitequark>
BitPuffin: hm?
<BitPuffin>
whitequark: the llvm thing
<whitequark>
probably
<BitPuffin>
well you can't just assume xD
<whitequark>
I can. ios is a popular platform and there's a lot of interest in rust
<whitequark>
it's safe to assume that the patch exists in some form
<whitequark>
which means that it exists but not in llvm trunk yet
<whitequark>
just build LLVM yourself
typedlambda has quit [Quit: bye.]
<BitPuffin>
hasn't landed is a bit ambigous
<BitPuffin>
although that's not what I meant by rust guys not so sure. I asked in the irc and they had no idea when the patch will come
typedlambda has joined #ocaml
<NoNNaN>
rust on ios and android, what is the current status of ocaml on ios and android ?
<NoNNaN>
or any experience with it
<whitequark>
a patchset for ios exists but is not merged
<whitequark>
and the build process is not exactly straightfoerward
<BitPuffin>
well
<BitPuffin>
guess I mighte use rust
<BitPuffin>
I'll keep using ocaml for my own website though
<orbitz>
depending on what you're doing you can use something like phonegap and js_of_ocaml
<BitPuffin>
need to interface with C so no
<tane>
rust can change easily between minor versions, what's the point in using that for production grade code?
<BitPuffin>
tane: it's pretty easy to change code accordingly
<BitPuffin>
with an emacs/vim macro
<BitPuffin>
plus you don't have to upgrade immediately
<BitPuffin>
it's not like if a new version comes out your code suddenly stops compiling
oriba_ has joined #ocaml
<tane>
the change from ~ to "Box<T>" and the box keyword was enough for me
<BitPuffin>
also it's starting to stabilize apparently
<BitPuffin>
mostly lib changes these days
<orbitz>
i wish i was interested in mobile dev so i coudl try to contirbute to streamlining ocaml on the phone
<whitequark>
there's been a lot of freezing in the rustland
<whitequark>
1.0 is high in priority
<tane>
whitequark, that sounds good
eikke__ has joined #ocaml
<BitPuffin>
orbitz: I wish I knew more about the compiler and stuff magically without having to put a bunch of hours into it so I could streamline it for the phone :P
<orbitz>
BitPuffin: i think most of it is just pushing to ge tthe patchset in and then cleaning up the interface, probably not much for compiler internals
oriba has quit [Ping timeout: 260 seconds]
<BitPuffin>
possibley
<BitPuffin>
wtf spelling. Possibly*
<BitPuffin>
I guess I should rephrase, I wish I had infinite time :P
malo has joined #ocaml
divyanshu has quit [Quit: Computer has gone to sleep.]
divyanshu has joined #ocaml
divyanshu has quit [Quit: Computer has gone to sleep.]
WraithM has quit [Ping timeout: 264 seconds]
orbitz has quit [Ping timeout: 240 seconds]
divyanshu has joined #ocaml
claudiuc has joined #ocaml
dsheets has quit [Ping timeout: 248 seconds]
eikke__ has quit [Ping timeout: 240 seconds]
tani has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
tane has quit [Ping timeout: 260 seconds]
ollehar1 has joined #ocaml
yacks has quit [Quit: Leaving]
orbitz has joined #ocaml
maattdd has joined #ocaml
manizzle has joined #ocaml
maattdd has quit [Ping timeout: 260 seconds]
yacks has joined #ocaml
hausdorff has joined #ocaml
hausdorff has quit [Remote host closed the connection]
BitPuffin has quit [Ping timeout: 255 seconds]
eikke__ has joined #ocaml
ollehar has quit [Ping timeout: 248 seconds]
robink has quit [Ping timeout: 240 seconds]
robink has joined #ocaml
hhugo has quit [Quit: Leaving.]
thomasga has joined #ocaml
hausdorff has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 264 seconds]
ygrek_ has quit [Ping timeout: 248 seconds]
slash^ has quit [Read error: Connection reset by peer]
jwatzman|work has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
Eyyub has quit [Ping timeout: 264 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
tnguyen1 has joined #ocaml
WraithM has joined #ocaml
divyanshu has joined #ocaml
lordkryss has quit [Ping timeout: 240 seconds]
_andre has quit [Quit: leaving]
hausdorff has quit [Ping timeout: 244 seconds]
yomimono has quit [Ping timeout: 240 seconds]
lordkryss has joined #ocaml
divyanshu has quit [Ping timeout: 252 seconds]
thomasga has quit [Quit: Leaving.]
Eyyub has joined #ocaml
Oejet has quit [Quit: Leaving.]
hausdorff has joined #ocaml
SethTisue has quit [Quit: SethTisue]
axiles has quit [Remote host closed the connection]
BitPuffin has joined #ocaml
BitPuffin has quit [Read error: Connection reset by peer]
BitPuffin has joined #ocaml
ggole has quit []
hhugo has joined #ocaml
hausdorff has quit [Remote host closed the connection]
Kakadu has quit [Quit: Konversation terminated!]
hausdorff has joined #ocaml
thomasga has joined #ocaml
jludlam has joined #ocaml
philtor_ has quit [Ping timeout: 252 seconds]
hausdorff has quit [Remote host closed the connection]
Thooms has joined #ocaml
patronus has joined #ocaml
bernardo1pc has joined #ocaml
rks__ has joined #ocaml
maxibolt has joined #ocaml
jonludlam_ has joined #ocaml
lusory_ has joined #ocaml
diethyl_ has joined #ocaml
Druup has joined #ocaml
bacam_ has joined #ocaml
marky_ has joined #ocaml
Cypi_ has joined #ocaml
bacam has quit [Disconnected by services]
bacam_ is now known as bacam
alpounet has quit [Ping timeout: 240 seconds]
bernardofpc has quit [Ping timeout: 240 seconds]
macron has quit [Ping timeout: 240 seconds]
seliopou has quit [Ping timeout: 240 seconds]
lusory has quit [Ping timeout: 240 seconds]
jludlam has quit [Ping timeout: 240 seconds]
diethyl has quit [Ping timeout: 240 seconds]
thizanne has quit [Ping timeout: 240 seconds]
testcocoon has quit [Ping timeout: 240 seconds]
Cypi has quit [Ping timeout: 240 seconds]
rks_ has quit [Ping timeout: 240 seconds]
Drup has quit [Ping timeout: 240 seconds]
patronus_ has quit [Ping timeout: 240 seconds]
jbrown has quit [Ping timeout: 240 seconds]
marky has quit [Ping timeout: 240 seconds]
yacks has quit [Ping timeout: 240 seconds]
maxibolt is now known as thizanne
yacks has joined #ocaml
Druup is now known as Drup
testcocoon has joined #ocaml
jbrown has joined #ocaml
seliopou has joined #ocaml
macron has joined #ocaml
Anarchos has quit [Ping timeout: 248 seconds]
jao has quit [Ping timeout: 260 seconds]
shinnya has joined #ocaml
mcclurmc has quit [Remote host closed the connection]
lordkryss_ has joined #ocaml
hhugo has quit [Quit: Leaving.]
lordkryss has quit [Ping timeout: 244 seconds]
Eyyub has quit [Ping timeout: 255 seconds]
lordkryss has joined #ocaml
lordkryss_ has quit [Ping timeout: 255 seconds]
philtor_ has joined #ocaml
WraithM has quit [Ping timeout: 252 seconds]
groovy2shoes has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 264 seconds]
Eyyub has joined #ocaml
Thooms has quit [Ping timeout: 264 seconds]
<mfp>
BitPuffin: I'm awefully late and just had a quick look at the logs, but... did you take a look at Lwt_preemptive.run_in_main ?
<mfp>
(i.e., Lwt_preemptive.detach inside a function evaluated by Lwt_preemptive.run_in_main)
rks__ is now known as rks`
fraggle_ has quit [Ping timeout: 252 seconds]
tani has quit [Quit: Verlassend]
maattdd has joined #ocaml
eikke__ has quit [Ping timeout: 240 seconds]
eikke__ has joined #ocaml
maattdd has quit [Ping timeout: 252 seconds]
darkf has joined #ocaml
<BitPuffin>
mfp: I did look at them but I am not the main thread and nor do I need a full thread pool
<mfp>
BitPuffin: run_in_main is specifically for the case where you're not in the main thread so...
<BitPuffin>
mfp: well no? you have to have started lwt in the main thread right?
<BitPuffin>
" in the main thread, i.e. the one executing Lwt_main.run "
jonludlam_ has quit [Ping timeout: 252 seconds]
<BitPuffin>
Lwt_main.run doesn't return until all the lwt processes are done
<mfp>
but the "main" thread can be any one you control that runs Lwt_main.run (guess)
<BitPuffin>
sure, but my threads don't run
<BitPuffin>
if I do Thread.delay it doesn't stop
<BitPuffin>
must be a bug
<mfp>
uh? OCaml does have preemption as long as you have allocations in your threads
<BitPuffin>
yeah but I'm pretty sure I tried both native and bytecode
<mfp>
so you'd have the thread doing Lwt_main.run that receives tasks via run_in_main, and then in parallel (with regularly preempted threads) your other stuff
<mfp>
what else do you do besides Thread.delay? IIRC there might have been/be some bug related to preemption somewhere in the bugtracker
<BitPuffin>
also tried Unix.sleep
<BitPuffin>
if that's what you mean :P
<BitPuffin>
basically I slept just because I wanted to see if the threads got anywhere because it seemed to exit execution before the threads finished executing
<BitPuffin>
which I don't believe is normal behaviour with threads
<BitPuffin>
doesn't the process wait for all the threads to finish usually?
<mfp>
rather: are there any allocations in your computations? (OCaml forces context switches at allocation points)
<BitPuffin>
mfp: only in native code as far as I'm aware
<mfp>
oh, were you doing Thread.join?
<BitPuffin>
but yeah I think there was some creating lists etc from web requests and stuff
<BitPuffin>
which should allocate
<BitPuffin>
no
<BitPuffin>
:o
<BitPuffin>
it's silly if that is it
<BitPuffin>
but it might be, however it doesn't explain the delaying and stuff
<BitPuffin>
however only switching context at allocation is pretty strange
<BitPuffin>
guess it's the single runtime thing
<mfp>
it needs to switch at a safe point, and there's allocation points handy
maattdd has joined #ocaml
<mfp>
~ same thing with signals
<BitPuffin>
yeah, well they are working on the concurrent gc, so that will be kewl
<BitPuffin>
either way, am I correct in my statement that the process doesn't stop until all the threads finish?
<mfp>
IIRC it'll quit as soon as the main one is done
<mfp>
if you don't Thread.join the ones you spawned
<BitPuffin>
ah, guess that's different from what I'm used to then
<mfp>
not 100% sure on that, but I believe it also bit me at some point (expecting the same thing as you)
madroach has quit [Ping timeout: 252 seconds]
<BitPuffin>
maybe the behaviour I described is more prevalent in languages that "know" about threads
madroach has joined #ocaml
groovy2shoes has quit [Ping timeout: 240 seconds]
maattdd has quit [Ping timeout: 244 seconds]
fraggle_ has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
fraggle_ has quit [Ping timeout: 260 seconds]
manizzle has quit [Remote host closed the connection]
manizzle has joined #ocaml
Sim_n has quit [Read error: Connection reset by peer]