calling C code // drivers

[Erik Stenman]

> Hi,
> 
> I sat and daydreamed today, and I have a few questions that I 
> hope someone will be kind enough to answer...
> 
> Are there any specific reasons to use the current way of 
> interfacing with C code (i.e. the drivers) as it is today 
> opposed to another one? What are the arguments for not using 
> a more direct way than today? What I have in mind is the fact 
> that with Hipe Erlang functions are compiled to native code - 
> in theory, I can't see any reason why one couldn't compile C 
> code to look like Hipe generated one. Thus we could have 
> everybody write their own BIFs!! :-) In any case, it would be 
> easier to interfacce with external libraries (and also the 
> result might be a little faster?)
> 
> Is this possible at all, or am I unaware of issues that forbid it?

Well, it is definitely possible, but I would advice against it, for
at least these two reasons:
 
 1. As the system is structured today there is only one emulator thread
    running. This means that when a BIF is called all other Erlang 
    processes are blocked. Hence, BIFs are *not allowed* to take a long time
    to execute. If you make a mistake or deadlock in the BIF everything
    blocks.

 2. There is no marshalling when calling BIFs. That means that the 
    BIFs have to deal directly with tagged Erlang values, and interact 
    with the GC and so on. Again if you make a mistake here the whole 
    system will crash, and often in very unpredictable ways. (Believe me,
    GC bug are not easy to find, even though the hunt might be fun in 
    a masochistic sort of way. ;)

For interfacing C, it is much safer to put your C-interface in 
a separate driver (or even better in a separate process and talk 
to it through a socket).

For efficiency, if you have a really, really time critical function 
which does not take a long time to execute ;) and it is simple to 
implement so you can be sure no mistakes are made, and no memory 
needs to be allocated then, maybe, maybe you could write your own 
BIF and link it into the system. But in that case you would probably 
be better off writing the function in Erlang and native code 
compiling it with HiPE.

Erik - HiPE Hacker.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3164 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030920/67f4d825/attachment.bin>