Language Bindings for Erlang Again

[Ulf Wiger]

Den 2006-06-06 15:52:21 skrev Yariv Sadan <yarivvv@REDACTED>:

>>
>> The long term, right approach would be to open the internals of
>> the emulator a little, but by reifying them cleanly, and to let
>> users write and load/unload dynamically their own BIFs.

You can do this pretty much today, since you can write linked-in drivers  
that are dynamically linked in (using erl_ddll), registered with a unique  
name, and called synchronously using port_call(). There are even support  
functions for letting the driver code return any erlang term. The main  
drawback compared to BIFs is that the data is copied between erlang and C.


> Unless I have a serious gap in understanding, isn't there another
> danger with letting developers essentially create their own BIFs,
> because BIF calls block the entire Erlang system process, hence
> blocking all spawned Erlang processes during their execution? If one
> could easily create BIFs, either they would have to be executed in a
> separate system thread, creating the same complexity with regards to
> communication with the Erlang VM, or developers would have to be
> pretty careful not to write BIFs such as synchronouslyDefragMyDrive()
> :)

Actually, creating BIFs is rather straightforward, as long as they do  
rather simple stuff. But there are lots of things one needs to understand  
about beam's memory management, etc., and it's not documented. You  
basically have to read other BIFs to find out how it's done.

BR,
Ulf W
-- 
Ulf Wiger