From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA12309; Thu, 1 Apr 2004 16:35:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA13309 for ; Thu, 1 Apr 2004 16:35:05 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i31EZ1YM000749 for ; Thu, 1 Apr 2004 16:35:03 +0200 Received: from [192.168.1.200] (ppp113-158.lns1.syd3.internode.on.net [150.101.113.158]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i31EYiwn013261; Fri, 2 Apr 2004 00:04:44 +0930 (CST) Subject: Re: [Caml-list] exene and ocaml ? From: skaller Reply-To: skaller@users.sourceforge.net To: Ville-Pertti Keinonen Cc: skaller@users.sourceforge.net, briand@aracnet.com, caml-list@pauillac.inria.fr In-Reply-To: <6C27A642-83BE-11D8-96B0-000393863F70@exomi.com> References: <16491.38344.186267.44292@soggy.deldotd.com> <1080807590.13854.260.camel@pelican> <6C27A642-83BE-11D8-96B0-000393863F70@exomi.com> Content-Type: text/plain Message-Id: <1080830083.13854.385.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 02 Apr 2004 00:34:44 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 callbacks:01 posix:01 threads:01 threading:01 model:01 9660:01 glebe:01 anyhow:01 ocaml:01 nsw:01 snail:02 checkout:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 18 On Thu, 2004-04-01 at 19:24, Ville-Pertti Keinonen wrote: [] Perhaps I can illustrate with a telco app. Consider a phone call using a Pre-Paid service. There is an algorithm which goes like: (1) Lookup the caller ID and see if they have a paid up account, if not exit. (2) Connect to the called number. (3) On hang up, charge them. Simple, right? Easy to do with callbacks. Unfortunately, the real world is more cruel. It goes like: Check if the caller has enough money to make the specified call. If so connect them. Estimate how long they can remain connected without running out of money. Schedule a disconnection at that time. Unfortunately, making that estimate is extremely difficult. Its not like everyone pays $1 per minute for a phone call, no matter where they're calling. What really happens is you have to check what kind of plan they have. Then you have to figure out what they should be paying for the particular call. The rate may depend on the time of day, and can change in the middle of the phone call. The rate also depends on the location being called. And what time it is there. And on the day of the week. ANd any special offers ... As you can imagine that calculation can require multiple database accesses, and even recursive calculations with possible trial computations. Given the weird business rules some telcos implement, I'd sure HATE to have a system in which each database request was satisfied by the DB calling back with the result of the last query. However, that is what physically happens: the database result is returned asynchronously. You can't hold the whole phone system up for 30 seconds while a slow DB is doing a search (but there's no problem making each caller wait around :D Using Posix threads here is out of the question. Even fast multi-CPU Sun boxes cannot switch at anywhere near the required rate -- but my 500Mhz Linux box has no trouble outperforming the Sun box using cooperative threading :D The reason of course is that selecting the next thread to run is determined by the next event in the queue directly, whereas an OS scheduler is asked to choose a thread on a much more complex basis that involves concepts like fairness. RT systems are unfair, they just throw out things they can't do -- in the telco world it is called 'call gapping' which means simply disconnecting people at random to reduce the load. Anyhow the situation is: event driven context switching is mandatory, but an even driven programming model is untenable. Three people took a year to do the C++ version. 1 guy took 3 days to prototype it in Felix (and he'd never seen Felix before). -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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