From: skaller <skaller@ozemail.com.au>
To: erayo@cs.bilkent.edu.tr
Cc: Caml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Need advice for a mobile application server
Date: 20 Nov 2003 16:34:35 +1100 [thread overview]
Message-ID: <1069306474.24578.76.camel@pelican> (raw)
In-Reply-To: <200311192003.37039.exa@kablonet.com.tr>
On Thu, 2003-11-20 at 05:03, Eray Ozkural wrote:
> Hello there,
>
> I am looking to consider ocaml for writing a multi-threaded application server
> which involves data structures of medium complexity (to be specific geometric
> structures). Do you think ocaml is a good bet for this purpose, or should I
> stick with C++? (in which I know how to write SMP code :)
>
> Will it be easy and efficient for me to implement imperative data structures
> which should be locked on update ops, but will not need such on queries (yes,
> I know it sounds naughty but it should be possible)? Or are there well known
> obstacles to performing such feats using our beloved ocaml?
Executive Summary [for lazy reader ..]: Use Ocaml.
I have written some multi-threaded client/server and peer2peer
Caml code for simulating a telephone network. For this purpose
I used module Event which is very good (once you get
the hang of it ..)
To create servers I modified the source code
of the Ocaml client/server function Unix.establish_server.
This function creates processes rather than threads,
and so I had to adapt it to threads which is quite easy.
My code was all native code using Posix threads,
it ran on both Linux and Solaris BUT be warned
that at least at that time (several years ago now)
Linux cannot create threads, only processes,
and consequently all threads are detached.
In the case of an error, the main thread can die
but the other threads can keep running ..
[this doesn't happen on Solaris and violates Posix,
I don't know whether this is fixed yet in Linux ..
in any case it has nothing to do with the choice
of Ocaml ..]
As usual I think Ocaml is superior *especially*
for complex tasks where abstractions with strong
guarrantees are highly desirable for reasoning
about software.
The only caveat I know of is that Ocaml
sometimes uses global locks (the gc can't
run concurrently with allocations etc)
and if you create C bindings for Ocaml you
have to be careful to make sure you manage
the exclusion correctly or you might end
up with a deadlock.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2003-11-20 6:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-19 18:03 Eray Ozkural
2003-11-20 5:34 ` skaller [this message]
2003-11-20 9:13 ` Richard Jones
2003-11-20 9:27 ` Xavier Leroy
2003-11-20 12:08 ` Eray Ozkural
2003-11-20 12:49 ` Basile Starynkevitch
[not found] ` <20031120161634.GA26689@redhat.com>
2003-11-21 8:48 ` Basile Starynkevitch
2003-11-21 17:06 ` skaller
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=1069306474.24578.76.camel@pelican \
--to=skaller@ozemail.com.au \
--cc=caml-list@inria.fr \
--cc=erayo@cs.bilkent.edu.tr \
/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