<Demitar>
The usual socket rules apply and the usual threading rules apply. :)
<Demitar>
Basically you'd have to keep a few things in mind: 1) make sure your external function calls are reentrant 2) don't access the same data from different threads 3) use the Event module to communicate stuff with the main thread 4) don't forget passing -thread when compiling and linking
<Demitar>
Personally I would avoid threads altogether (if possible).
gpciceri has quit [Remote closed the connection]
<mflux>
avoiding threads good.
<Riastradh>
What's wrong with threads?
<mflux>
using threads usually requires synchronization, which is difficult :)
<Riastradh>
Note Demitar's suggestion to use the Event module.
<Demitar>
Riastradh, apart from shooting oneself in the foot, I'm mostly concerned with the difficulty of killing threads.
<mflux>
if thread's only interface to the system is the Event-module, such a problem could be avoided
<Demitar>
If you have make sure you never deadlock in a thread (to be able to shut it down) you kind of defeat the control-inversion purpose of using threads.
<Demitar>
(Thus I use them sparingly, mostly to do blocking function calls non-blockingly, connect() and gethostbyname() being the most obvious cases.)
pango has joined #ocaml
<Riastradh>
What do you mean 'you defeat the control-inversion purpose of using threads?'
<Demitar>
Riastradh, if I have to make sure I never block indefinitely (deadlock) I can't write code as linearly as would otherwise be possible.
<Demitar>
The linearity being the control inversion, the same thing any multitasking system does.
<Riastradh>
Demitar, are you referring to the potential problems of a rudimentary mutual exclusion mechanism?
<Demitar>
Riastradh, I think you lost /me/ this time. :)
<Riastradh>
Uh, you know what 'mutual exclusion' is, right?
<Demitar>
Riastradh, yes, but my tired brain can't connect so many big words at once right now. (Haven't slept for too long. :)
<Riastradh>
OK: are you referring to the deadlock that can occur if you're using simplistic locks to synchronize shared memory access?
<Riastradh>
(I hope my attempt at simplifying & clarifying the wording there was successful.)
<Demitar>
Riastradh, no, I'm more concerned with leaking threads.
<Demitar>
Riastradh, very. :)
<Riastradh>
OK, now _you've_ lost _me_!
<mflux>
you're both lost ;(
* Riastradh
asks around for a map.
<mflux>
maybe demitar is worried about that if a thread is blocked on read(), it cannot be killed?
<Demitar>
Riastradh, well it's quite possible I do something that will block endlessly (I don't have a good example handy) and thus it will never return. Also it makes joining threads a _lot_ trickier.
<Demitar>
mflux, something in that direction.
<Riastradh>
If the resource from which to read is terminated, the blocked read could just raise an exception.
<mflux>
but what if closing the descriptor isn't an option for some reason?
<Demitar>
mflux, [ioframework] I've been pondering something which is probably quite similar. A socket_server, probably using classes to get nice vtables, which would be derived into tcp_server, http_server, irc_server, foo_server, ...
<mflux>
demitar, did you check out the 'application examples' at the end?
<Riastradh>
mflux, have you considered building this into CML/the Event module?
<mflux>
riastradh, well at some point it did occur to me that infact the event module is very similar to this
<mflux>
basically the only difference is the syntax
<Demitar>
Riastradh, in general those seemingly clean and simple uses get icky fast, note that I'm mostly using threads when dealing with some kind of io and the lowlevel interfaces probably make my view fairly biased.
<mflux>
I return lists, and as lists are ocaml builtin data types, there is no extra syntax involved
<mflux>
but atleast some kind of an interface to the Event module could be ninice
<Riastradh>
Not exactly, mflux. Event is generalized; your framework is specific to I/O.
<mflux>
well, it depends how you view it
<mflux>
Event is specific to ipc :)
<Riastradh>
Not at all.
<mflux>
it has 'fill in blanks' for generalizing
<Demitar>
I assume the framework abstracts IO into events, that's the point, no?
<Riastradh>
It's not presented very well in the manual.
<mflux>
that I must say
<Riastradh>
Events are the important thing. Channels are only a particular way to use the event system.
<mflux>
the only way I figured out the 'real' way to use event was by some example for concurrent ml
CosmicRay has quit ["Leaving"]
<Smerdyakov>
mflux, that's the intention. It wouldbe wasted effort to re-document CML.
<mflux>
well maybe it could atleast have a pointer to such documentation, because I had to hunt for it :)
<mflux>
I think it does mention cml though
<mflux>
let's say I wanted to write a timer for ocaml's Event, as it doesn't have such.. can I?
<mflux>
well, I could of course have a thread that did that, but..
<Smerdyakov>
Hm, too bad. CML has that built in. :)
mrvn_ has joined #ocaml
<mflux>
maybe I should do a better comparison, but now that I think of it I think there are some differences between the api and ioframework.ml
<mflux>
but something like that could be written on top of Event
<jason_>
But, it's not huge in the "useless info taking up room" kind of way.
<jason_>
Like, once you get through it, you'll wonder how they hell they fit so much into so little room.
<jason_>
Just one thing after another. Like, I honestly knew more about programming concepts in general after reading it. Knowing the syntax of Ocaml is secondary.
<Riastradh>
There are many who would say about SICP what you say about this OCaml book.
<jason_>
I'll check it out.
<jason_>
Thanks :)
<jason_>
Yeah, I printed the Ocaml Ora book out at Kinkos.
<jason_>
Heh.
<stef>
ho, apparently the installation of ocaml shoved me some .el file in site-lisp
<stef>
tuareg is better than that stuff?
<Riastradh>
Yes.
<stef>
ok
<stef>
good to know
<jason_>
I put the tuareg stuff in my site-lisp directory on my Gentoo machine at work.
<jason_>
But, it screwed a bunch of stuff up some how.
<jason_>
Like.. My .emacs file needed some other things.
<jason_>
I have it working on my laptop here though.
<jason_>
I've just been using vi at work.
<jason_>
Hm, maybe I should just copy my .emacs from here to there ;) Hehe.
<stef>
I will switch back to vi the day it will support shell buffers
<stef>
emacs is so messy
<jason_>
Blah.
<jason_>
Shell buffer schmell buffers.
<jason_>
Hm, what'do you guys think of FreeBSD?
* monochrom
whispers Eclipse and runs
monochrom has quit ["hello"]
<Riastradh>
Yet another Unix, jason_. Uninteresting.
<mellum>
Riastradh: But it has less users than Linux, so it must be cooler
<avlondono>
stef: isn't gnu screen good enough?
CosmicRay has joined #ocaml
<jason_>
Hm.
<jason_>
Unix is definitely ineresting :0
<jason_>
I think everything is interesting.
<Riastradh>
Unix might have been interesting as a lightweight & easily portable OS in 1970.
<jason_>
Hm, so, what operating systems are 'more' interesting these days?
<Riastradh>
Not many. Real OS research died over a decade ago.
<jason_>
And, you forget how many programming languages came about in the late 70's that are still somewhat interesting.
<jason_>
Hm, ever seen "Plan 9"?
* Riastradh
doesn't forget that.
<Riastradh>
A bit; I am unimpressed.
<jason_>
Hm, why? Distributed operating systems.
<jason_>
Not such a bad idea.
<Riastradh>
Distribution isn't very interesting to me if it's just distribution of the same old thing.
<jason_>
Hm. I think it's very interesting. A lot of potential fo rit.
<jason_>
The ability to levy out massive computations to other machines.
<jason_>
All over the internet.
<Riastradh>
There have been almost no radical OS concepts presented in the last decade.
<jason_>
Like, a computation cluster that just forms out of every computer on the planet.
<Riastradh>
Parallelization & distribution aren't new or innovative.
<jason_>
In an operating system, they definitely are.
<Riastradh>
Certainly not. They've been around for much longer than a decade.
<avlondono>
with that logic Riastradh, nothing on earth is innovative or new.
<jason_>
I mean, the storage of information and the presentation of it wasn't 'new' or innovative either. But making it massively available via the internet was definitely interesting.
<jason_>
I mean, what you're talking about is extremely local, and naive views of the actual realization of a massive internet based virtual computer.
<jason_>
Yeah, it's like Neuton said, he figured out realtively nothing in his entire life span. His major advancements came about by "Standing on the shoulders of Giants."
<Riastradh>
With that insult to my logic, avlondono, you have not made me care to elaborate on my statements. I'm uninterested in discussing anything with people who randomly insult me thus.
<jason_>
By taking old ideas, integrating them, and forming something new.
<avlondono>
beh, easy to insult you are
<avlondono>
:P
<jason_>
I'm assuming since you said 'people' you're including me in the matter.
<Riastradh>
I have been attacked with great vigour on frivolous matters at least four times in the past couple days, and I'm sick of it.
<avlondono>
and I don't see how my commentary was insulting
<Riastradh>
jason_, no, but I'm now in a foul mood.
<avlondono>
it's not my fault how your daily life is.
<jason_>
Hm.. Well, your views are simply being doubted ;) I really didn't mean to 'attack' you by any means. I'm incredibly sorry if I've offended you.
<avlondono>
so I won't discuss anything, it was productive for jason_
CosmicRay has quit ["Leaving"]
<avlondono>
please, don't stop it because of me.
<Riastradh>
jason_, no, I'm not claiming you attacked me or offended me.
<jason_>
Okay :) I'm sorry though-- I was just meaning to have a friendly debate over the matter.
<jason_>
I really wouldn't enage in a discussion with you if I didn't feel you were intelligent, and your opinion likely valid.