Re: [Caml-list] exene and ocaml ?

[skaller <skaller@users.sourceforge.net>]

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