Language Bindings for Erlang Again
Tue Jun 6 20:21:06 CEST 2006
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.
More information about the erlang-questions