Using hardware in Erlang

[Inswitch Solutions - Erlang Evaluation]

Hello Vance,

Thanks for your reply!
Eduardo is out of the Office today, but let me try to clarify a little
bit more what he meant. We were discussing with him yesterday, the
general system software architecture, considering specifically where and
how to implement Earlang code in the different modules of the systems.

In our system, (a prepaid system) we do have a couple of modules, with
computer telephony boards in it. These boards all come with "Windows
APIs for C, C++" (specifically, one of these apis, communicates with the
device drivers through Win32 System calls). And theses modules are
"clients" of an application server, which controls them by sending them
commands and receiving events from them. Erlang should fit very well in
both the application server and the database. 

Eduardo's question is if Erlang fits within the application server's
clients (the computer telephony modules with the apis). 

As Erlang seems to be robust for administrating threads resources, he
was trying to use Erlang to administrate the multi threads into these
computer telephony modules, instead of doing it through Windows threads
programming.     

Thanks again,

Regards,

Daniel

Daniel Fernandez

INswitch Solutions
T. 5989-9667353


-----Mensaje original-----
De: owner-erlang-questions@REDACTED
[mailto:owner-erlang-questions@REDACTED] En nombre de Vance Shipley
Enviado el: viernes, 29 de noviembre de 2002 5:56
Para: Inswitch Solutions - Erlang Evaluation
CC: erlang-questions@REDACTED
Asunto: Re: Using hardware in Erlang

Eduardo,

Since you used the word "synchronous" I would suggest that you try using
erl_interface to build your device driver.  In this method you would
write
a C program to interface with the hardware.  This program would send and
receive Erlang messages using the erl_interface API and libraries.  Your
Erlang/OTP node, where your real applications are hosted, would
interface
to the hardware by sending native Erlang messages back and forth to the
"C node".  Your C code is free to use blocking calls and other dangerous
activities.

The other approach is to use a linked in driver.  Here you again write
C code but it is a library which is linked against the Erlang runtime 
system.  Your hardware interfacing code is now part of the Erlang
runtime
and must follow the rules.  One of which is certainly not to block!
You can use blocking functions if you must but then you'll have to
implement
a threading driver and have all blocking calls done in threads.  The
complexity climbs quickly here.

I'd go with the erl_interface method first.  If you find later that you
want a more tightly coupled interface you can change it.

We at Motivity use both types of drivers.  Which is best depends on the
method that we interface to the hardware mostly.  In the one case we use
Dialogic hardware boards which come with a Unix device driver.  The API
for this driver does not use standard file descriptors.  It does allow
asynchronous usage but because it doesn't use file descriptors we cannot
use poll/select to wait on events/completions.  This model really
doesn't
work in the linked in driver model.

A third method for attaching hardware to the system is through direct
TCP/IP messaging.  Many hardware systems we are seeing these days
provide
their API over an ethernet (or cPCI PSB) interface instead of the PCI
bus.
For these you would use inet in Erlang and enjoy no C code at all.

	-Vance

Vance Shipley
Motivity Telecom Inc.
+1 519 240 3684
	
On Fri, Nov 29, 2002 at 07:24:55PM +0100, Inswitch Solutions - Erlang
Evaluation wrote:
}  
}  I?m evaluating Erlang and I?d like to know the best choice for
calling hardware synchronous mode functions. 
}  I read about linked-driver but I?m not sure if it's the right way.
}  
}  
}  Thanks in advance,
}  Eduardo Figoli
}  INSwitch
}  
}